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本 书 介绍 了 在 Java 编 程 中 78 条 极 具 实 用 价值 的 经 验 规则 ,这些 经 验 规则 涵盖 了 大 多 
数 开发 人 员 每 天 所 面临 的 问题 的 解决 方案 。 通 过 对 Java 平 台 设 计 专家 所 使 用 的 技术 的 全 
面 描述 ， 揭 示 子 应 该 做 什么 ,不 应 该 做 什么 才能 产生 清晰 、 健 壮 和 高 效 的 代码 。 第 2 版 反 
映 了 Java 5 中 最 重要 的 变化 ， 并 删 去 了 过 时 的 内 容 。 

本 书 中 的 每 条 规则 都 以 简短 、 独 立 的 小 文章 形式 出 现 ， 并 通过 示例 代码 加 以 进一步 
说 明 。 本 书 内 容 全 面 ， 结 构 清晰 ， 讲 解 详细 。 可 作为 技术 人 员 的 参考 用 书 。 
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译 者 序 


Java 从 诞生 到 日 趋 完善 ， 经 过 了 不 断 的 发 展 壮 大 ， 目 前 全 世界 拥有 了 成 千 上 万 的 Java 开 发 
人 员 。 如 何 编写 出 更 清晰 、 更 正确 、 更 健壮 且 更 易于 重用 的 代码 ， 是 大 家 所 追求 的 目标 之 一 。 
作为 经 典 Jolt 获 奖 作品 的 新 版 书 ， 它 已 经 进行 了 彻底 的 更 新 ， 涵 盖 了 自 第 1 版 之 后 所 引入 的 
Java SE 5 和 Java SE 6 的 新 特性 。 作 者 探索 了 新 的 设计 模式 和 语言 习惯 用 法 ， 介 绍 了 如 何 充 分 
利用 从 泛 型 到 枚 举 、 从 注解 到 自动 装 箱 的 各 种 特性 。 本 书 的 作者 Joshua Bloch 曾 经 是 Sun 公 司 
的 杰出 工程 师 ， 带 领 团队 设计 和 实现 过 无 数 的 Java 平 台 特 性 ， 包 括 JDK 5.0 语 言 增强 版 和 获奖 
的 Java Collections Framework。 他 也 是 Jolt 奖 的 获得 者 ， 现 在 担任 Google 公 司 的 首席 Java 架 构 
师 。 他 为 我 们 带 来 了 共 78 条 程序 员 必 备 的 经 验 法 则 : 针对 你 每 天 都 会 遇 到 的 编程 问题 提出 了 
最 有 效 、 最 实用 的 解决 方案 。 


书 中 的 每 一 章 都 包含 几 个 “条 目 ”"， 以 简洁 的 形式 呈现 ， 自 成 独立 的 短文 ， 它 们 提出 了 具 
体 的 建议 、 对 于 Java 平 台 精妙 之 处 的 独到 见解 ， 并 提供 优秀 的 代码 范例 。 每 个 条 目的 综合 描述 
和 解释 都 益 明 了 应 该 怎么 做 、 不 应 该 怎么 做 ， 以 及 为 什么 。 通过 贯穿 全 书 透彻 的 技术 剖析 与 
完整 的 示例 代码 ， 仔 细 研 读 并 加 以 理解 与 实践 ， 必 定 会 从 中 受益 匪 浅 。 书 中 介绍 的 示例 代码 
清晰 易 懂 ， 也 可 以 作为 日 常 工 作 的 参考 指南 。 


适合 人 群 


本 书 不 是 针对 初学 者 的 ， 读 者 至 少 需要 熟悉 Java 程 序 设计 语言 。 如 果 你 连 equals()、 
toString()、hashCode() 都 还 不 了 解 的 话 ， 建 议 先 去 看 些 优秀 的 Java 入 门 书籍 之 后 再 来 阅读 本 
书 。 如 果 你 现在 已 经 在 Java 开 发 方面 有 了 一 定 的 经 验 ， 而 且 想 更 加 深入 地 了 解 Java 编 程 语言 ， 
成 为 一 名 更 优秀 、 更 高 效 的 Java 开 发 人 人员， 那么， 建议 你 用 心地 研读 本 书 。 


内 容 形 式 


本 书 分 为 11 章 共 78 个 条 目 ， 涵 盖 了 Java 5.0 / 6.0 的 种 种 技术 要 点 。 与 第 1 版 相 比 ， 本 书 删 
除了 “C 语 言 结构 的 替代 ”一 章 ， 增 加 了 Java 5 所 引入 的 “ 泛 型 "*、“ 枚 举 和 注解 ”各 一 章 。 数 
量 上 从 57 个 条 目 发 展 到 了 78 个 ， 不 仅 增加 了 23 个 条 目 ， 并 对 原来 的 所 有 资料 都 进行 了 全 面 的 
修改 ， 删 去 了 一 些 已 经 过 时 的 条 目 。 但 是 ， 各 章节 没有 严格 的 前 后 顺序 关系 ， 你 可 以 随意 选 
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择 感 兴趣 的 章节 进行 阅读 。 当 然 ， 如 果 你 想 马上 知道 第 2 版 究竟 有 哪些 变化 ， 可 以 参阅 附录 中 
第 2 版 与 第 1 版 详细 的 对 照 情况 。 


本 书 重点 讲述 了 Java 5 所 引入 的 全 新 的 泛 型 、 枚 举 、 注 解 、 自 动 装 箱 、for-each 循 环 、 可 
变 参 数 、 并 发 机 制 ， 还 包括 对 象 、 类 、 类 库 、 方 法 和 序列 化 这 些 经 典 主 题 的 全 新 技术 和 最 佳 
实践 ， 如 何 避 免 Java 编 程 语言 中 常 被 误解 的 细微 之 处 ， 陷阱 和 缺陷 ， 并 重点 关注 Java 语 言 本 身 
和 最 基本 的 类 库 : java.lang、java.util， 以 及 一 些 扩展 ， java.util.concurrent 和 java.io 等 等 。 


章节 简介 


第 2 章 曾 述 何 时 以 及 如 何 创建 对 象 ， 何 时 以 及 如 何 避 免 创 建 对 象 ， 如 何 确保 它们 能 够 被 适 
时 地 销毁 ， 以 及 如 何 管理 销毁 之 前 必须 进行 的 所 有 清除 动作 。 


第 3 章 曾 述 对 于 所 有 对 象 都 通用 的 方法 ， 你 会 从 中 获知 对 equals、hashCode、 toString 、 
clone 和 finalize 相 当 深 入 的 分 析 ， 从 而 避免 今后 在 这 些 问题 上 再 次 犯错 。 


第 4 章 阐述 作为 Java 程 序 设计 语言 的 核心 以 及 Java 语 言 的 基本 抽象 单元 (类 和 接口 )， 在 使 用 
上 的 一 些 指导 原则 ， 帮 助 你 更 好 地 利用 这 些 元 素 ， 设 计 出 更 加 有 用 、 健 壮 和 灵活 的 类 和 接口 。 


第 5 和 第 6 章 中 分 别 阐述 在 Java 1.5 发 行 版 本 中 新 增加 的 泛 型 (Generic) 以 及 枚 举 和 注解 的 
最 佳 实践 ， 教 你 如 何 最 大 限度 地 享有 这 些 优势 ， 又 能 使 整个 过 程 尽 可 能 地 简单 化 。 


第 7 章 讨论 方法 设计 的 几 个 方面 : 如 何 处 理 参数 和 返回 值 ， 如 何 设计 方法 签名 ， 如 何 为 方 
法 编写 文档 。 从 而 在 可 用 性 、 健 壮 性 和 灵活 性 上 有 进一步 的 提升 。 


第 8 章 主要 讨论 Java 语 言 的 具体 细节 ， 讨 论 了 局 部 变量 的 处 理 、 控 制 结构 、 类 库 的 使 用 、 
各 种 数据 类 型 的 用 法 ， 以 及 两 种 不 是 由 语言 本 身 提供 的 机 制 (reflection 和 native method， 反 
射 机 制 和 本 地 方法 ) 的 用 法 。 并 讨论 了 优化 和 命名 惯例 。 


第 9 章 益 述 如何 充 分 发 挥 异常 的 优点 ， 可 以 提高 程序 的 可 读 性 :可 靠 性 和 可 维护 性 ， 以 及 
减少 使 用 不 当 所 带 来 的 负面 影响 。 并 提供 了 一 些 关于 有 效 使 用 异常 的 指导 原则 。 


第 10 章 曾 述 如 何 帮助 你 编写 出 清晰 、 正 确 、 文 档 组 织 良好 的 并 发 程序 。 


第 11 章 阐述 序列 化 方面 的 技术 ， 并 且 有 一 项 值得 特别 提 及 的 特性 ， 就 是 序列 化 代理 
(serialization proxy) 模式 ， 它 可 以 帮助 你 避免 对 象 序列 化 的 许多 缺陷 。 


举 个 例子 ， 就 序列 化 技术 来 讲 ，HTTP 会 话 状 态 为 什么 可 以 被 缓存 ? RMI 的 异常 为 什么 可 
以 从 服务 器 端 传递 到 客户 端 呢 ? GUI 组 件 为 什么 可 以 被 发 送 、 保 存 和 恢复 呢 ? 是 因为 它们 实现 
了 Serializable 接 口 吗 ? 如 果 超 类 没有 提供 一 个 可 访问 的 无 参 构造 器 ， 它 的 子 类 可 以 被 序列 化 
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吗 ? 当 一 个 实例 采用 默认 的 序列 化 形式 ， 并 且 给 某 些 域 标记 为 transient， 那 么 当 实 例 反 序列 化 
回来 后 ， 这 些 标志 为 transient 域 的 值 各 是 些 什 么 呢 ?…… 这 些 问 题 如 果 你 现在 不 能 马上 回答 ， 
或 者 不 能 很 确定 ， 没 有 关系 ,仔细 阅读 本 书 ， 你 会 对 它们 有 更 深入 与 透彻 的 理解 。 


技术 范围 


虽然 本 书 是 讨论 更 深层 次 的 Java 开 发 技术 ,讲述 的 内 容 深入 ， 涉 及 面 又 相当 广泛 ,但 是 它 
并 没有 涉及 图 形 用 户 界面 编程 、 企 业 级 API 以 及 移动 设备 方面 的 技术 ， 不 过 在 各 个 章节 与 条 目 
会 不 时 地 讨论 到 其 他 相关 的 类 库 。 


这 是 一 本 分 享 经 验 与 指引 你 避免 走 弯路 的 经 典 著 作 ， 针 对 如 何 编 写 高 效 、 设 计 优 良 的 程序 
提出 了 最 实用 、 最 权威 的 指导 方针 ， 是 Java 开 发 人 员 案 头 上 的 一 本 不 可 或 缺 的 参考 书 。 


本 书 由 我 组 织 进行 翻译 ， 第 1 章 到 第 8 章 由 杨 春花 负责 ， 我 负责 前 言 、 附 录 以 及 第 9 章 到 第 
11 章 的 翻译 ， 并 负责 本 书 所 有 章节 的 全 面 审 校 。 参 与 翻译 和 审 校 的 还 有 : R, MKA, D 
EE, MGF, KAA, EMR, PRIMA, RATE. EB. MMIC. WEK, ER, PERI, 
罗 兴 、 翟 育 明 、 黄 华 ， 在 此 深 表 感谢 。 


虽然 我 们 在 翻译 过 程 中 竭力 追求 信 、 达 、 雅 ， 但 限于 自身 水 平 ， 也 许 仍 有 不 足 ， 还 望 各 位 
读者 不 音 指正 。 关 于 本 书 的 翻译 和 翻译 时 采用 的 术语 表 以 及 相关 的 技术 讨论 大 家 可 以 访问 我 
的 博客 http://blog.csdn.net/YuLimin， 也 可 以 发 邮件 到 YuLimin @ 163.com 与 我 交流 。 

在 这 里 ， 我 要 感谢 在 翻译 过 程 中 一 起 讨论 并 帮助 我 的 朋友 们 ， 他 们 是 : BR, WE, AR 
fe, MER, ， 满 江 红 开放 技术 研究 组 织 创始 人 曹 晓 钢 ，Spring 中 文 站 创始 人 杨 戈 (Yanger), 


SpringSide 创 始 人 肖 桦 (江南 白衣 ) 和 来 自 宝 岛 台湾 的 李 日 贵 (jini)、 林 康 司 (koji), kia R 
(caterpillar) ， 还 有 责任 编辑 陈 佳 媛 也 为 本 书 出 版 做 了 大 量 工作 ， 在 此 再 次 深 表 感 谢 。 


快乐 分 享 ， 实 践 出 真知 ， 最 后 ， 祝 大 家 能 够 像 我 一 样 在 阅读 中 享受 本 书 带 来 的 乐趣 ! 


Read a bit and take it out, then come back read some more. 


俞 歼 敏 
2008 年 11 月 
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如 果 有 一 个 同事 这 样 对 你 说 ,“ 我 的 配偶 今天 晚上 在 家 里 制造 了 一 顿 不 同 寻 常 的 晚餐 ， 你 
愿意 来 参加 吗 ?”(Spouse of me .this night today manufactures the unusual meal in a home. 
You will join?) 这 时 候 你 脑子 里 可 能 会 浮现 起 三 件 事情 : 第 一 ， 满 脑子 的 疑惑 ， 第 二 ， 英 语 
肯定 不 是 这 位 同事 的 母语 ， 第 三 ， 同 事 是 在 邀请 你 参加 他 的 家 庭 晚 宴 。 


如 果 你 曾经 学 习 过 第 二 种 语言 ， 并 且 尝 试 过 在 课堂 之 外 使 用 这 种 语言 ， 你 就 该 知道 有 三 件 
事情 是 必须 掌握 的 : 这 门 语言 的 结构 如 何 ( 语 法 )， 如 何 命名 你 想 谈论 的 事物 (词汇)， 以 及 
如 何以 惯用 和 高 效 的 方式 来 表达 日 常 的 事物 (用法)。 在 课堂 上 大 多 只 涉及 前 面 两 点 ， 当 你 使 
出 浑身 解数 想 让 对 方 明白 你 的 意思 时 ， 常 常会 发 现 当 地 人 对 你 的 表述 忍俊不禁 。 


程序 设计 语言 也 是 如 此 。 你 需要 理解 语言 的 核心 : 它 是 面向 算法 的 ， 还 是 面向 函数 的 ， 或 者 
是 面向 对 象 的 ?你 需要 知道 词汇 表 : 标准 类 库 提供 了 哪些 数据 结构 、 操 作 和 功能 (Facility) ? 
你 还 需要 熟悉 如 何 用 习惯 和 高 效 的 方式 来 构建 代码 。 关 于 程序 设计 语言 的 书籍 通常 只 是 涉及 
前 面 两 点 ， 或 者 只 是 晴 贱 点 水 般 地 介绍 一 下 用 法 。 也 许 是 因为 前 面 两 点 比较 容易 编写 。 语 法 
和 词汇 是 语言 本 身 固有 的 特性 ， 但 是 ， 用 法 则 反映 了 使 用 这 门 语言 的 群体 的 特征 。 


例如 ,Java 程 序 设计 语言 是 一 门 支 持 单 继承 的 面向 对 象 程序 设计 语言 , 在 每 个 方法 的 内 部 ， 
它 也 支持 命令 式 的 (面向 语句 的 ，Statement-Oriented) 编码 风格 。Java 类 库 提 供 了 对 图 形 
显示 、 网 络 、 分 布 式 计算 和 安全 性 的 支持 。 但 是 ， 如 何 把 这 门 语言 以 最 佳 的 方式 运用 到 实践 
中 呢 ? 


还 有 一 点 : 程序 与 口语 中 的 句子 以 及 大 多 数 书籍 和 杂志 都 不 同 ， 它 会 随 着 时 间 的 推移 而 发 
生变 化 。 仅 仅 编写 出 能 够 有 效 地 工作 并 且 能 够 被 别人 理解 的 代码 往往 是 不 够 的 ， 我 们 还 必须 
把 代码 组 织 成 易于 修改 的 形式 。 针 对 某 个 任务 可 能 会 有 10 种 不 同 的 编码 方法 ， 而 在 这 10 种 方 
法 中 ， 有 7 种 方法 是 笨拙 的 、 低 效 的 或 者 是 难以 理解 的 。 而 在 剩 下 的 3 种 编码 方法 中 ， 哪 一 种 
会 是 最 接近 该 任务 的 下 一 年 度 发 行 版 本 的 代码 呢 ? 


目前 有 大 量 的 书籍 可 以 供 你 学 习 Java 程 序 设计 语言 的 语法 ， 包 括 《The Java Programming 
Language》[Arnold05] (作者 Arnold、Gosling 和 Holmes)， 以 及 《The Java Language Specification) 
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ULS] (作者 Gosling、Joy 和 Bracha) 。 同 样 ， 与 Java 程 序 设计 语言 相关 的 类 库 和 API 的 书籍 也 不 少 。 


本 书 解决 了 你 的 第 三 种 需求 : 习惯 和 高 效 的 用 法 。 作 者 Joshua Bloch 在 Sun 公 司 多 年 来 一 
直 从 事 Java 语 言 的 扩展 、 实 现 和 使 用 的 工作 ， 他 还 大 量 地 阅读 了 其 他 人 的 代码 , 包括 我 的 代码 。 
他 在 本 书 中 提出 了 许多 很 好 的 建议 ， 他 系统 地 把 这 些 建议 组 织 起 来 ， 旨 在 告诉 读者 如 何 更 好 
地 构造 代码 以 便 它们 能 工作 得 更 好 ， 也 便于 其 他 人 能 够 理解 这 些 代 码 ， 便 于 将 来 对 代码 进行 
修改 和 改善 的 时 候 不 至 于 那么 头疼 。 甚 至 ， 你 的 程序 也 会 因此 而 变 得 更 加 令 人 愉悦 、 更 加 优 
美和 雅致 。 


Guy L. Steele Jr. 
Burlington, Massachusetts 
2001 年 4 月 
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自从 我 于 2001 年 写 了 本 书 的 第 1 版 之 后 ，Java 平 台 又 发 生 了 很 多 变化 ， 是 该 出 第 2 版 的 时 个 
T. Java 5 中 最 为 重要 的 变化 是 增加 了 泛 型 、 枚 举 类 型 、 注 解 、 自 动 装 箱 和 for-each 循 环 。 其 次 


是 增加 了 新 的 并 发 类 库 ; java.util.concurrent。 我 和 Gilad Bracha 一 起 ， 有 幸 带 领 团队 设计 了 最 新 
的 语言 特性 。 我 还 有 幸 参加 了 设计 和 开发 并 发 类 库 的 团队 ， 这 个 团队 由 Doug Lea 领 导 。 


例如 Eclipse、IntelliJ IDEA 和 NetBeans， 以 及 静态 分 析 工 具 的 IDE， 如 FindBugs。 虽 然 我 
影响 。 


Java 平 台中 另 一 个 大 的 变化 在 于 广泛 采用 了 现代 的 IDE (Integrated Development Environment) , 
还 未 参与 到 这 部 分 工作 ,但 已 经 从 中 受益 芥 浅 ， 并 且 很 清楚 它们 对 Java 开 发 体验 所 带 来 的 


2004 年 ， 我 离开 Sun 公 司 到 了 Google 公 司 工作 ， 但 在 过 去 的 4 年 中 ， 我 仍然 继续 参与 Java 
平台 的 开发 ， 在 Google 公 司 和 JCP (Java Community Process) 的 大 力 帮助 下 ， 继 续 并 发 和 集 
名 用 户 的 感受 。 


合 API 的 开发 。 我 还 有 率 利用 Java 平 台 去 开发 供 Google 内 部 使 用 的 类 库 。 现 在 我 了 解 了 作为 一 


我 在 2001 年 编写 第 1 版 的 时 候 ， 主 要 目的 是 与 读者 分 享 我 的 经 验 ， 便 于 让 大 家 能 够 避免 我 
所 走 过 的 弯路 ， 使 大 家 更 容易 成 功 。 新 版 仍然 大 量 采用 来 自 Java 平 台 类 库 的 真实 范例 。 


第 1 版 所 带 来 的 反应 远 远 超出 了 我 最 大 的 预期 。 我 在 收集 所 有 新 的 资料 以 使 本 书 保持 最 新 
时 ， 尽 可 能 地 保持 了 资料 的 真实 。 毫 无 疑问 ， 本 书 的 篇 幅 肯定 会 增加 ， 从 57 个 条 目 发 展 到 了 


78 个 。 我 不 仅 增加 了 23 个 条 目 ， 并 且 修 改 了 原来 的 所 有 资料 ， 并 删 去 了 一 些 已 经 过 时 的 条 目 。 
在 附录 中 ， 你 可 以 看 到 本 书 中 的 内 容 与 第 1 版 的 内 容 的 对 照 情 况 。 
在 第 1 版 的 前 言 中 我 说 过 : Java 程 序 设计 语言 和 它 的 类 库 非 常 有 益 于 代码 质量 和 效率 的 提 


高 ， 并 且 使 得 用 Java 进 行 编码 成 为 一 种 乐趣 。Java 5 和 6 发 行 版 本 中 的 变化 是 好 事 ， 也 使 得 
Java 平 台 日 趋 完善 。 现 在 这 个 平台 比 2001 年 的 要 大 得 多 ， 也 复杂 得 多 ， 但 是 一 旦 掌握 了 使 用 
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新 特性 的 模式 和 习惯 用 法 ， 它 们 就 会 使 你 的 程序 变 得 更 完美 ， 使 你 的 工作 变 得 更 轻松 。 我 希 
望 第 2 版 能 够 体现 出 我 对 Java 平 台 持续 的 热情 ， 并 将 这 种 热情 传递 给 你 ， 帮 助 你 更 加 高 效 和 愉 
快 地 使 用 Java 平 台 及 其 新 的 特性 。 


Joshua Bloch 
San Jose, California 
2008 年 4 月 
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第 1 章 


S| 


本 书 的 目标 是 帮助 读者 最 有 效 地 使 用 Java 程 序 设计 语言 及 其 基本 类 库 ，java lang 
java.util， 在 某 种 程度 上 还 包括 java.util.concurrent 和 java.io。 本 书 也 会 不 时 地 讨论 到 其 他 的 类 
库 ， 但 是 没有 涉及 图 形 用 户 界 面 编程 、 企 业 级 API 以 及 移动 设备 相关 的 类 库 。 


本 书 共 包含 78 个 条 目 ， 每 个 条 目 讨 论 一 条 规则 。 这 些 规 则 反映 了 最 有 经 验 的 优秀 程序 员 在 
实践 中 常用 的 一 些 有 益 做 法 。 本 书 以 一 种 比较 自由 的 方式 将 这 些 条 目 组 织 成 10 章 ， 每 一 章 都 涉 
及 软件 设计 的 一 个 主要 方面 。 本 书 并 不 一 定 要 按部就班 地 从 头 读 到 尾 ， 因 为 每 个 条 目 都 有 一 定 
程度 的 独立 性 。 这 些 条 目 相互 之 间 交 叉 引 用， 因此 你 可 以 很 容易 地 在 书 中 找到 自己 需要 的 内 容 。 


Java 5 (发 行 版 本 1.5) 中 增加 了 许多 新 特性 。 本 书 中 大 多 数 条 目 都 以 一 定 的 方式 用 到 了 
这 些 特性 。 表 1-1 列 出 了 这 些 特性 所 在 的 主要 章节 或 条 目 。 


表 1-1 新 增 特性 所 在 章节 或 条 目 









所 在 章节 或 条 目 所 在 章节 或 条 目 







泛 型 第 5 章 自动 装 箱 第 40、49 条 
枚 举 第 30 一 34 条 varargs 第 42 条 
注解 第 35 一 37 条 MEFA 第 19 条 
for-each 循 环 第 46 条 java.util.concurrent 68, 69% 






大 多 数 条 目 都 通过 程序 示例 进行 说 明 。 本 书 一 个 突出 的 特点 是 ， 包 含 了 许多 代码 示例 ， 这 
些 例子 说 明了 许多 设计 模式 (Design Pattern) 和 习惯 用 法 (Idiom) 。 当 需要 参考 设计 模式 领 
域 的 标准 参考 书 [Gamma 95] 时 ， 还 为 这 些 设计 模式 和 习惯 用 法 提供 了 交叉 引用 。 


许多 条 目 都 包含 有 一 个 或 多 个 应 该 在 实践 中 避免 的 程序 示例 。 像 这 样 的 例子 ， 有 时 候 也 叫 
做 “ 反 模 式 (Antipattern)”， 在 注释 中 清楚 地 标注 为 “//Never do this!”"。 对 于 每 种 情况 ， 条 
目 中 都 解释 了 为 什么 此 例 不 好 ， 并 提出 了 另外 的 解决 方法 。 


2 PIE 


本 书 并 不 是 针对 初学 者 的 : 本 书 假 设 读者 已 经 熟悉 Java 程 序 设计 语言 。 如 果 你 还 没有 做 到 , 
请 考虑 先 参 阅 一 本 很 好 的 Java 入 门 书籍 [Arnold05，Sestoft05]。 本 书 的 目标 是 适用 于 任何 具有 
实际 Java 工 作 经 验 的 程序 员 ， 对 于 高 级 程序 员 ， 也 应 该 能 够 提供 一 些 发 人 深思 的 东西 。 


本 书 中 大 多 数 规则 都 源 于 少数 几 条 基本 的 原则 。 清 晰 性 和 简洁 性 最 为 重要 : 模块 的 用 户 永 
远 也 不 应 该 被 模块 的 行为 所 迷惑 (那样 就 不 清晰 了 ) ， 模块 要 尽 可 能 小 ， 但 又 不 能 太 小 [本 
书 中 使 用 的 术语 模块 (Module) ， 是 指 任何 可 重用 的 软件 组 件 ， 从 单个 方法 ， 到 包含 多 个 包 的 
复杂 系统 ， 都 可 以 是 一 个 模块 ] 。 代 码 应 该 被 重用 ， 而 不 是 被 拷贝 。 模 块 之 间 的 依赖 性 应 该 
尽 可 能 地 降 到 最 小 。 错 误 应 该 尽早 被 检测 出 来 ， 最 好 是 在 编译 时 刻 。 


虽然 本 书 中 的 规则 不 会 百分之百 地 适用 于 任何 时 刻 和 任何 场合 ， 但 是 ， 它 们 确实 体现 了 绝 
大 多 数 情况 下 的 最 佳 程序 设计 实践 。 你 不 应 该 盲目 地 遵从 这 些 规 则 ， 但 是 ， 你 应 该 只 在 偶尔 
的 情况 下 ， 有 了 充分 理由 之 后 才 去 打破 这 些 规则 。 同 大 多 数学 科 一 样 ， 学 习 编 程 艺 术 首 先 要 
学 会 基本 的 规则 ， 然 后 才能 知道 什么 时 候 可 以 打破 这 些 规则 。 


本 书 大 部 分 内 容 都 不 是 讨论 性 能 的 ， 而 是 关心 如 何 编写 出 清晰 、 正 确 、 可 用 、 健 壮 、 灵 活 
和 可 维护 的 程序 来 。 如 果 你 能 够 做 到 这 一 点 的 话 ， 那 么 要 想 获 得 所 需要 的 性 能 往往 就 相对 比 
较 简 单 了 ( 见 第 55 条 )。 有 些 条 目 确实 谈 到 了 性 能 问题 ， 甚 至 有 的 还 提供 了 性 能 指标 。 但 是 ， 
在 提 及 这 些 指标 的 时 候 ， 也 会 出 现 “ 在 我 的 机 器 上 ”这 样 的 话 ， 所 以 ， 你 最 好 把 这 些 指 标 视 
同 近似 值 。 - 

有 必要 提 及 的 是 ， 我 的 机 器 是 一 台 过 时 的 家 用 电脑 ， 主 机 为 2.2 GHz 双核 AMD Opteron 
170，2G 内 存 ， 在 Microsoft Windows XP Professional SP2 操 作 系 统 平 台 上 运行 Sun 1.6_05 发 
行 版 本 的 Java SE Development Kit (JDK)。 这 个 JDK 有 两 台 虚 拟 机 : Java HotSpot Clienti 
Server VM。 性 能 指标 是 在 Server VM 上 测量 的 。 


讨论 Java 程 序 设计 语言 及 其 类 库 特性 的 时 候 ， 有 了 时候 必须 要 指明 具体 的 发 行 版 本 。 为 了 简 
单 起 见 ， 本 书 使 用 了 工程 版 本 号 (engineering version number)， 而 不 是 正式 的 发 行 名 称 。 表 
1-2 列 出 了 发 行 名 称 与 工程 版 本 号 之 间 的 对 应 关系 。 


表 1-2 Java 的 工程 版 本 号 





正式 发 行 名 称 工程 版 本 号 
JDK 1.1.x / JRE 1.1.x 1,1 
Java 2 Platform, Standard Edition, v 1.2 12 
Java 2 Platform, Standard Edition, v 1.3 6 1.3 
Java 2 Platform, Standard Edition, v 1.4 1.4 
Java 2 Platform, Standard Edition, v 5.0 Lp 


Java Platform, Standard Edition 6 1.6 
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尽管 这 些 例子 都 很 完整 ， 但 是 它们 注重 可 读 性 更 其 于 注重 完整 性 。 它 们 直接 使 用 了 
java.util 和 java.io 包 中 的 类 。 为 了 编译 这 些 示例 程序 ， 可 能 需要 在 程序 中 加 上 一 行 或 者 多 行 这 
样 的 import 语 句 : 

import java.util.«; 


import java.util.concurrent.«; 
import java.io.«; 


其 他 代码 示例 中 也 有 类 似 被 省 略 的 情况 。 但 是 ， 在 本 书 的 Web 站 点 : http://java.sun.com/ 
docs/books/effective， 提 供 了 每 个 示例 的 完整 版 本 ， 你 可 以 直接 编译 和 运行 这 些 示例 。 


本 书 采用 的 大 部 分 技术 术语 都 与 《The Java Language Specification, Third Edition) 
[JLS] 相同 。 有 一 些 术 语 则 值得 特别 提出 来 。Java 语 言 支持 四 种 类 型 接口 (interface)、 类 
(class) 、 数 组 (array) 和 基本 类 型 (primitive) 。 前 三 种 类 型 通常 被 称 为 引用 类 型 (reference 
type) ， 类 实例 和 数组 是 对 象 (object) ， 而 基本 类 型 的 值 则 不 是 对 象 。 类 的 成 员 (member) 
由 它 的 域 (field)、 方 法 (method), Ae HAE (member class) 和 成 员 接口 (member interface) 
组 成 。 方 法 的 签名 (signature) 由 它 的 名 称 和 所 有 参数 类 型 组 成 ， 签 名 不 包括 它 的 返回 类 型 。 


本 书 也 使 用 了 一 些 与 《The Java Language Specification) 不 同 的 术语 。 与 《The Java 
Language Specification》 不 同 的 是 ， 本 书 用 术语 “继承 (inheritance)” 作 为 “ 子 类 化 
(subclassing)” 的 同义词 。 本 书 不 再 使 用 “接口 继承 ”这 种 说 法 ， 而 是 简单 地 说 ， 一 个 类 实现 
(implement) 了 一 个 接口 ， 或 者 一 个 接口 扩展 (extend) 了 另 一 个 接口 。 为 了 描述 “在 没有 指 
定 访问 级 别 的 情况 下 所 使 用 的 访问 级 别 ”， 本 书 使 用 了 描述 性 的 术语 “ 包 级 私有 (package- 
private )”， 而 不 是 如 [JLS, 6.6.1] 中 所 使 用 的 技术 性 术语 “ 缺 省 访问 (default access) 级 别 ”。 


本 书 也 使 用 了 一 些 在 《The Java Language Specification》 中 没有 定义 的 技术 术语 。 术 语 
“导出 的 API (exported API)”， 或 者 简单 地 说 API， 是 指 类 、 接 口 、 构 造 器 (constructor)、 
成 员 和 序列 化 形式 (serialized form)， 程 序 员 通 过 它们 可 以 访问 类 、 接 口 或 者 包 。( 术 语 API 
是 Application Programming Interface 的 简写 ， 这 里 之 所 以 使 用 API 而 不 用 接口 (interface), 
是 为 了 不 与 Java 语 言 中 的 interface 类 型 相 混 请 ) 。 使 用 API 编 写 程序 的 程序 员 被 称 为 该 API 的 用 
户 (user)， 在 类 的 实现 中 使 用 了 API 的 类 被 称 为 该 API 的 客户 (client)。 


类 、 接 口 、 构 造 器 、 成 员 以 及 序列 化 形式 被 统称 为 API 元 素 (API element)。 导 出 的 API 
由 所 有 可 在 定义 该 API 的 包 之 外 访问 的 API 元 素 组 成 。 任 何 客户 端 都 可 以 使 用 这 些 API 元 素 ， 
而 API 的 创建 者 则 负责 支持 这 些 API 元 素 。Javadoc 工 具 类 在 默认 操作 模式 下 也 正 是 为 这 些 元 素 
生成 文档 ， 这 绝 非 偶然 。 不 严格 地 讲 ， 一 个 包 的 导出 的 API 是 由 该 包 中 的 每 个 公有 (public) 
类 或 者 接口 中 所 有 公有 的 或 者 受 保护 的 (protected) 成 员 和 构造 器 组 成 。 


O ”该 书 影印 版 《Java 语言 规范 》 由 机 械 工业 出 版 社 引 进出 版 ， 书 号 是 : 7-111-18839。 一 一 编辑 注 





第 2 章 
创建 和 销毁 对 象 


本 章 的 主题 是 创建 和 销毁 对 象 : 何 时 以 及 如 何 创建 对 象 ， 何 时 以 及 如 何 避免 创建 对 象 ， 
如 何 确保 它们 能 够 适时 地 销毁 ， 以 及 如 何 管理 对 象 销毁 之 前 必须 进行 的 各 种 清理 动作 。 





对 于 类 而 言 ， 为 了 让 客户 端 获取 它 自身 的 一 个 实例 ， 最 常用 的 方法 就 是 提供 一 个 公有 的 构 
造 器 。 还 有 一 种 方法 ， 也 应 该 在 每 个 程序 员 的 工具 箱 中 占有 一 席 之 地 。 类 可 以 提供 一 个 公有 


的 静态 工厂 方法 (static factory method)， 它 只 是 一 个 返回 类 的 实例 的 静态 方法 。 下 面 是 一 个 
来 自 Boolean (基本 类 型 boolean 的 包装 类 ) 的 简单 示例 。 这 个 方法 将 boolean 基 本 类 型 值 转换 
成 了 一 个 Boolean 对 象 引 用 : 


public static Boolean valueOf(boolean b) { 
return b ? Boolean.TRUE : Boolean. FALSE; 


注意 ， 静 态 工厂 方法 与 设计 模式 [Gamma95, p.107] 中 的 工厂 方法 模式 不 同 。 本 条 目 中 所 指 
的 静态 工厂 方法 并 不 直接 对 应 于 设计 模式 中 的 工厂 方法 。 


类 可 以 通过 静态 工厂 方法 来 提供 它 的 客户 端 ， 而 不 是 通过 构造 器 。 提 供 静态 工厂 方法 而 不 
是 公有 的 构造 器 ， 这 样 做 具有 几 大 优势 。 


静态 工厂 方法 与 构造 器 不 同 的 第 一 大 优势 在 于 ， 它 们 有 名 称 。 如 果 构 造 器 的 参数 本 身 没 有 
确切 地 描述 正 被 返回 的 对 象 ， 那 么 具有 适当 名 称 的 静态 工厂 会 更 容易 使 用 ， 产 生 的 客户 端 代 
码 也 更 易于 阅读 。 例 如 ， 构 造 器 BigInteger (int, int, Random) 返回 的 BigInteger 可 能 为 素数 ， 
如 果 用 名 为 BigInteger.probablePrime 的 静态 工厂 方法 来 表示 ， 显 然 更 为 清楚 。(1.4 的 发 行 版 本 
中 最 终 增 加 了 这 个 方法 。) 


一 个 类 只 能 有 一 个 带 有 指定 签名 的 构造 器 。 编 程 人 员 通 常 知道 如 何 避 开 这 一 限制 : 通过 提 
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供 两 个 构造 器 ， 它 们 的 参数 列表 只 在 参数 类 型 的 顺序 上 有 所 不 同 。 实 际 上 这 并 不 是 个 好 主意 。 
面 对 这 样 的 API， 用 户 永远 也 记 不 住 该 用 哪个 构造 器 ， 结 果 常 常会 调用 错误 的 构造 器 。 并 且 ， 
读 到 使 用 了 这 些 构造 器 的 代码 时 ， 如 果 没 有 参考 类 的 文档 ， 往 往 不 知 所 云 。 


由 于 静态 工厂 方法 有 名 称 ， 所 以 它们 不 受 上 述 的 限制 。 当 一 个 类 需要 多 个 带 有 相同 签名 的 构 
造 器 时 ， 就 用 静态 工厂 方法 代替 构造 器 ， 并 且 慎 重地 选择 名 称 以 便 突出 它们 之 间 的 区 别 。 


静态 工厂 方法 与 构造 器 不 同 的 第 二 大 优势 在 于 ， 不 必 在 每 次 调用 它们 的 时 候 都 创建 一 个 新 
对 象 。 这 使 得 不 可 变 类 ( 见 第 15 条 ) 可 以 使 用 预先 构建 好 的 实例 ， 或 者 将 构建 好 的 实例 缓存 
起 来 ， 进 行 重复 利用 ， 从 而 避免 创建 不 必要 的 重复 对 象 。Boolean.valueOf(boolean) 方 法 说 明 
了 这 项 技术 : 它 从 来 不 创建 对 象 。 这 种 方法 类 似 于 Flyweight 模 式 [Gamma95 p.195], mR 
序 经 常 请 求 创 建 相 同 的 对 象 ， 并 且 创 建 对 象 的 代价 很 高 ， 则 这 项 技术 可 以 极 大 地 提升 性 能 。 


静态 工厂 方法 能 够 为 重复 的 调用 返回 相同 对 象 ， 这 样 有 助 于 类 总 能 严格 控制 在 某 个 时 刻 哪 
些 实例 应 该 存在 。 这 种 类 被 称 作 实 例 受 挖 的 类 (instance-controlled ) 。 编 写实 例 受 控 的 类 有 几 
个 原因 。 实 例 受 控 使 得 类 可 以 确保 它 是 一 个 Singleton ( 见 第 3 条 ) 或 者 是 不 可 实例 化 的 ( 见 第 4 
条 )。 它 还 使 得 不 可 变 的 类 ( 见 第 15 条 ) 可 以 确保 不 会 存在 两 个 相等 的 实例 ， 即 当 且 仅 当 a== 
的 时 候 才 有 a.equals(b) 为 ture。 如 果 类 保证 了 这 一 点 ， 它 的 客户 端 就 可 以 使 用 == 操 作 符 来 代替 
equals (Object) 方法 ， 这 样 可 以 提升 性 能 。 枚 举 (enum) 类 型 ( 见 第 30 条 ) 保证 了 这 一 点 。 


静态 工厂 方法 与 构造 器 不 同 的 第 三 大 优势 在 于 ， 它 们 可 以 返回 原 返 回 类 型 的 任何 子 类 型 的 
对 象 。 这 样 我 们 在 选择 返回 对 象 的 类 时 就 有 了 更 大 的 灵活 性 。 


这 种 灵活 性 的 一 种 应 用 是 ，API 可 以 返回 对 象 ， 同 时 又 不 会 使 对 象 的 类 变 成 公有 的 。 以 这 
种 方式 隐藏 实现 类 会 使 API 变 得 非常 简洁 。 这 项 技术 适用 于 基于 接口 的 框架 (interface-based 
framework， 见 第 18 条 ) ， 因 为 在 这 种 框架 中 ， 接 口 为 静态 工厂 方法 提供 了 自然 返回 类 型 。 接 
口 不 能 有 静态 方法 ， 因 此 按照 惯例 ， 接 口 Type 的 静态 工厂 方法 被 放 在 一 个 名 为 Types 的 不 可 实 
例 化 的 类 ( 见 第 4 条 ) 中 。 


例如 ，Java Collections Framework 的 集合 接口 有 32 个 便利 实现 ， 分 别提 供 了 不 可 修改 的 
集合 、 同 步 集合 等 等 。 几 乎 所 有 这 些 实现 都 通过 静态 工厂 方法 在 一 个 不 可 实例 化 的 类 (java. 
util.Collections) 中 导出 。 所 有 返回 对 象 的 类 都 是 非 公有 的 。 


现在 的 Collections Framework API 比 导出 32 个 独立 公有 类 的 那 种 实现 方式 要 小 得 多 ， 每 种 
便利 实现 都 对 应 一 个 类 。 这 不 仅仅 是 指 API 数 量 上 的 减少 ,也 是 概念 意义 上 的 减少 。 用 户 知道 ， 
被 返回 的 对 象 是 由 相关 的 接口 精确 指定 的 ， 所 以 他 们 不 需要 阅读 有 关 的 类 文档 。 使 用 这 种 静 
态 工厂 方法 时 ， 甚 至 要 求 客 户 端 通过 接口 来 引用 被 返回 的 对 象 ， 而 不 是 通过 它 的 实现 类 来 引 
用 被 返回 的 对 象 ， 这 是 一 种 良好 的 习惯 ( 见 第 52 条 )。 
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公有 的 静态 工厂 方法 所 返回 的 对 象 的 类 不 仅 可 以 是 非 人 双 有 的 ， 而 且 该 类 还 可 以 随 着 每 次 调 
用 而 发 生变 化 ， 这 取决 于 静态 工厂 方法 的 参数 值 。 只 要 是 已 声明 的 返回 类 型 的 子 类 型 ， 都 是 
允许 的 。 为 了 提升 软件 的 可 维护 性 和 性 能 ， 返 回 对 象 的 类 也 可 能 随 着 发 行 版 本 的 不 同 而 不 同 。 


发 行 版 本 1.5 中 引入 的 类 java.util.EnumSet ( 见 第 32 条 ) 没有 公有 构造 器 ， 只 有 静态 工厂 
方法 。 它 们 返回 两 种 实现 类 之 一 ， 有 具体 则 取决 于 底层 枚 举 类 型 的 大 小 : 如 果 它 的 元 素 有 64 个 
或 者 更 少 ， 就 像 大 多 数 枚 举 类 型 一 样 ， 静 态 工 厂 方法 就 会 返回 一 个 RegalarEumSet 实 例 ， 用 单 
个 long 进 行 支持 ， 如 果 枚 举 类 型 有 65 个 或 者 更 多 元 素 ， 工 厂 就 返回 JumboEnumSet 实 例 ， 用 
long 数 组 进行 支持 。 l 


这 两 个 实现 类 的 存在 对 于 客户 端 来 说 是 不 可 见 的 。 如 果 RegularEnumSet 不 能 再 给 小 的 枚 
举 类 型 提供 性 能 优势 ， 就 可 能 从 未 来 的 发 行 版 本 中 将 它 删 除 ， 不 会 造成 不 良 的 影响 。 同 样 地 ， 
如 果 事 实证 明 对 性 能 有 好 处 ， 也 可 能 在 未 来 的 发 行 版 本 中 添加 第 三 甚至 第 四 个 EnumSet 实 现 。 
客户 端 永远 不 知道 也 不 关心 他 们 从 工厂 方法 中 得 到 的 对 象 的 类 ， 他 们 只 关心 它 是 EnumSet 的 某 
个 子 类 即 可 。 


静态 工厂 方法 返回 的 对 象 所 属 的 类 ， 在 编写 包含 该 静态 工厂 方法 的 类 时 可 以 不 必 存 在 。 这 
种 灵活 的 静态 工厂 方法 构成 了 服务 提供 者 框架 (Service Provider Framework) 的 基础 ， 例 如 
JDBC (Java 数 据 库 连 接 , Java Database Connectivity) API。 服 务 提供 者 框架 是 指 这 样 一 个 系 
统 : 多 个 服务 提供 者 实现 一 个 服务 ， 系 统 为 服务 提供 者 的 客户 端 提供 多 个 实现 ， 并 把 他 们 从 
多 个 实现 中 解 耦 出 来 。 


服务 提供 者 框架 中 有 三 个 重要 的 组 件 : 服务 接口 (Service Interface) ， 这 是 提供 者 实现 
A; 提供 者 注册 API (Provider Registration API) ， 这 是 系统 用 来 注册 实现 ， 让 客户 端 访问 它 
们 的 ， 服 务 访问 API (Service Access API) ， 是 客户 端 用 来 获取 服务 的 实例 的 。 服 务 访问 API 
一 般 人 允许 但 是 不 要 求 客户 端 指定 某 种 选择 提供 者 的 条 件 。 如 果 没 有 这 样 的 规定 ，API 就 会 返回 
默认 实现 的 一 个 实例 。 服 务 访问 API 是 “灵活 的 静态 工厂 ”， 它 构成 了 服务 提供 者 框架 的 基础 。 


服务 提供 者 框架 的 第 四 个 组 件 是 可 选 的 : 服务 提供 者 接口 (Service Provider Interface), ix 
些 提 供 者 负责 创建 其 服务 实现 的 实例 。 如 果 没 有 服务 提供 者 接口 ， 实 现 就 按照 类 名 称 注册 ， 并 
通过 反射 方式 进行 实例 化 ( 见 第 53 条 )。 对 于 JDBC 来 说 ，Connection 就 是 它 的 服务 接口 ， 
DriverManager.registerDriver 是 提供 者 注册 API，DriverManager.get Connection 是 服务 访问 API， 
Driver 就 是 服务 提供 者 接口 。 


服务 提供 者 框架 模式 有 着 无 数 种 变 体 。 例 如 ， 服 务 访问 API 可 以 利用 适配器 (Adapter) 
模式 [Gamma95，p.139]， 返 回 比 提供 者 需要 的 更 丰富 的 服务 接口 。 下 面 是 一 个 简单 的 实现 ， 
包含 一 个 服务 提供 者 接口 和 一 个 默认 提供 者 : 
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// Service provider framework sketch 


// Service interface 
public interface Service { 

... // Service-specific methods go here 
} 


// Service provider interface 

public interface Provider { 
Service newService(); 

} 


// Noninstantiable class for service registration and access 
public class Services { 
private Services() { } // Prevents instantiation (Item 4) 


// Maps service names to services 
private static final Map<String, Provider> providers = 
new ConcurrentHashMap<String, Provider>(); 
public static final String DEFAULT_PROVIDER_NAME = "<def>"; 


// Provider registration API 
public static void registerDefaultProvider(Provider p) { 
registerProvider(DEFAULT_PROVIDER_NAME, p); 


} 
public static void registerProvider(String name, Provider p){ 
providers.put(name, p); 


// Service access API 
public static Service newInstance() { 
return newInstance(DEFAULT_PROVIDER_NAME) ; 
public static Service newInstance(String name) { 
Provider p = providers.get(name) ; 
if (p == null) 
throw new I]legalArgumentException( 


"No provider registered with name: " + name); 
return p.newService(); 


} 


静态 工厂 方法 的 第 四 大 优势 在 于 ， 在 创建 参数 化 类 型 实例 的 时 候 ， 它 们 使 代码 变 得 更 加 简 
洁 。 遗 憾 的 是 ， 在 调用 参数 化 类 的 构造 器 时 ， 即 使 类 型 参数 很 明显 ， 也 必须 指明 。 这 通常 要 
求 你 接连 两 次 提供 类 型 参数 : 


Map<String, List<String>> m = 
new HashMap<String, List<String>>(); 


随 着 类 型 参数 变 得 越 来 越 长 ， 越 来 越 复 杂 ， 这 一 元 长 的 说 明 也 很 快 变 得 痛苦 起 来 。 但 是 有 
了 静态 工厂 方法 ， 编 译 器 就 可 以 替 你 找到 类 型 参数 。 这 被 称 作 类 型 推导 (type inference), fil 
如 ， 假 设 HashMap 提 供 了 这 个 静态 工厂 : 


public static <K, V> HashMap<K, V> newInstance() { 
return new HashMap<K, V>(); 
} 


你 就 可 以 用 下 面 这 句 简洁 的 代码 代替 上 面 这 段 繁琐 的 声明 : 
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Map<String, List<String>> m = HashMap.newInstance(); 


总 有 一 天 ，Java 将 能 够 在 构造 器 调用 以 及 方法 调用 中 执行 这 种 类 型 推导 ， 但 到 发 行 版 本 
1.6 为 止 暂时 还 无 法 这 么 做 。 


遗憾 的 是 ， 到 发 行 版 本 1.6 为 止 ， 标 准 的 集合 实现 如 HashMap 并 没有 工厂 方法 ,但 是 可 以 
把 这 些 方法 放 在 你 自己 的 工具 类 中 。 更 重要 的 是 ， 可 以 把 这 样 的 静态 工厂 放 在 你 自己 的 参数 
化 的 类 中 。 


静态 工厂 方法 的 主要 缺点 在 于 , 类 如 果 不 含 公有 的 或 者 受 保护 的 构造 器 , 就 不 能 被 子 类 化 。 
对 于 公有 的 静态 工厂 所 返回 的 非 公有 类 ， 也 同样 如 此 。 例 如 ， 要 想 将 Collections Framework 
中 的 任何 方便 的 实现 类 子 类 化 ， 这 是 不 可 能 的 。 但 是 这 样 也 许 会 因祸得福 ， 因 为 它 鼓励 程 序 
员 使 用 复合 (composition), ， 而 不 是 继承 ( 见 第 16 条 ) 。 


静态 工厂 方法 的 第 二 个 缺点 在 于 ， 它 们 与 其 他 的 静态 方法 实际 上 没有 任何 区 别 。 在 API 文 
” 档 中 ， 它 们 没有 像 构造 器 那样 在 API 文 档 中 明确 标识 出 来 ， 因 此 ， 对 于 提供 了 静态 工厂 方法 而 
不 是 构造 器 的 类 来 说 ， 要 想 查 明 如 何 实例 化 一 个 类 ， 这 是 非常 困难 的 。Javadoc 工 具 总 有 一 天 
会 注意 到 静态 工厂 方法 。 同 时 ， 你 通过 在 类 或 者 接口 注释 中 关注 静态 工厂 ， 并 遵守 标准 的 命 
名 习惯 ， 也 可 以 弥补 这 一 劣势 。 下 面 是 静态 工厂 方法 的 一 些 惯用 名 称 : 


“valueOf 一 一 不 太 严 格 地 讲 ， 该 方法 返回 的 实例 与 它 的 参数 具有 相同 的 值 。 这 样 的 静态 工 
厂 方法 实际 上 是 类 型 转换 方法 。 


e of 一 一 valueOf 的 一 种 更 为 简洁 的 替代 ， 在 EnumSet ( 见 第 32 条 ) 中 使 用 并 流行 起 来 。 


“getInstance 一 一 返回 的 实例 是 通过 方法 的 参数 来 描述 的 ， 但 是 不 能 够 说 与 参数 具有 同样 
的 值 。 对 于 Singleton 来 说 ， 该 方法 没有 参数 ， 并 返回 唯一 的 实例 。 


* newlInstance 一 一 像 getInstance 一 样 ， 但 newInstance 能 够 确保 返回 的 每 个 实例 都 与 所 有 其 
他 实例 不 同 。 





"get7ype 一 一 像 getInstance 一 样 ， 但 是 在 工厂 方法 处 于 不 同 的 类 中 的 时 候 使 用 。 Type 表示 
工厂 方法 所 返回 的 对 象 类 型 。 


“new7Type 一 一 像 newinstance 一 样 ， 但 是 在 工厂 方法 处 于 不 同 的 类 中 的 时 候 使 用 。mype 表 
示 工 厂 方法 所 返回 的 对 象 类 型 。 


简 而 言 之 ， 静态 工厂 方法 和 公有 构造 器 都 各 有 用 处 ， 我 们 需要 理解 它们 各 自 的 长 处 。 静态 
工厂 通常 更 加 合适 ， 因 此 切忌 第 一 反应 就 是 提供 公有 的 构造 器 ， 而 不 先 考虑 静态 工厂 。 
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静态 工厂 和 构造 器 有 个 共同 的 局 限 性 : 它们 都 不 能 很 好 地 扩展 到 大 量 的 可 选 参数 。 考 虑 用 
一 个 类 表示 包装 食品 外 面 显示 的 营养 成 份 标签 。 这 些 标签 中 有 几 个 域 是 必需 的 : 每 份 的 含量 、 
每 镀 的 含量 以 及 每 份 的 卡路里 ， 还 有 超过 20 个 可 选 域 . 总 脂肪 量 、 饱 和 脂肪 量 、 转 化 脂肪 、 
胆固醇 、 钠 等 等 。 大 多 数 产品 在 某 几 个 可 选 域 中 都 会 有 非 零 的 值 。 


对 于 这 样 的 类 ， 应 该 用 哪 种 构造 器 或 者 静态 方法 来 编写 呢 ? 程序 员 一 向 习惯 采用 重 释 构造 
器 (telescoping constructor) 模式 ， 在 这 种 模式 下 ， 你 提供 第 一 个 只 有 必要 参数 的 构造 器 ， 第 
二 个 构造 器 有 一 个 可 选 参数 ， 第 三 个 有 两 个 可 选 参数 ， 依 此 类 推 ， 最 后 一 个 构造 器 包含 所 有 
可 选 参数 。 下 面 有 个 示例 ， 为 了 简单 起 见 ， 它 只 显示 四 个 可 选 域 : 


// Telescoping constructor pattern - does not scale well! 
public class NutritionFacts { 


private final int servingSize; // (mL) required 
private final int servings; // (per container) required 
private final int calories; | // optional 
private final int fat; ' // (9) optional 
private final int sodium; // (mg) optional 
private final int carbohydrate; // (g) optional 


public NutritionFacts(int servingSize, int servings) { 
this(servingSize, servings, 0); 


public NutritionFacts(int servingSize, int servings, 
int calories) { 
this(servingSize, servings, calories, @); 


public NutritionFacts(int servingSize, int servings, 
int calories, int fat) { 
this(servingSize, servings, calories, fat, 0); 


public NutritionFacts(int servingSize, int servings, 
int calories, int fat, int sodium) { 
this(servingSize, servings, calories, fat, sodium, 0); 


public NutritionFacts(int servingSize, int servings, 
int calories, int fat, int sodium, int carbohydrate) { 
this.servingSize = servingSize; 


this.servings = servings; 
this.calories = calories; 
this. fat = fat; 
this.sodium = sodium; 
this.carbohydrate = carbohydrate; 


} 
} 


当 你 想 要 创建 实例 的 时 候 ， 就 利用 参数 列表 最 短 的 构造 器 ， 但 该 列表 中 包含 了 要 设置 的 所 
有 参数 : 
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NutritionFacts cocaCola = 
new NutritionFacts(240, 8, 100, 0, 35, 27); 


这 个 构造 器 调用 通常 需要 许多 你 本 不 想 设置 的 参数 ， 但 还 是 不 得 不 为 它们 传递 值 。 在 这 个 
例子 中 ， 我 们 给 fat 传 递 了 一 个 值 为 0。 如 果 “ 仅 仅 ”是 这 6 个 参数 ， 看 起 来 还 不 算 太 粳 ， 问 题 
是 随 着 参数 数目 的 增加 ， 它 很 快 就 失去 了 控制 。 


. 一 旬 话 : 重 登 构造 器 模式 可 行 ， 但 是 当 有 许多 参数 的 时 候 ， 客 户 广 代码 会 很 难 编写 ， 并 上 且 
仍然 较 难以 阅读 。 如 果 读 者 想 知道 那些 值 是 什么 意思 ， 必 须 很 仔细 地 数 着 这 些 参 数 来 探 个 究 
竟 。 一 长 串 类 型 相同 的 参数 会 导致 一 些微 妙 的 错误 。 如 果 客 户 端 不 小 心 颠 倒 了 其 中 两 个 参数 
的 顺序 ， 编 译 器 也 不 会 出 错 ， 但 是 程序 在 运行 时 会 出 现 错误 的 行为 。 


遇 到 许多 构造 器 参数 的 时 候 ， 还 有 第 二 种 代替 办 法 ， 即 JavaBeans 模 式 ， 在 这 种 模式 下 ， 
调用 一 个 无 参 构造 器 来 创建 对 象 ， 然 后 调用 setter 方 法 来 设置 每 个 必要 的 参数 ， 以 及 每 个 相关 
的 可 选 参数 : 

// JavaBeans Pattern - allows inconsistency, mandates mutability 

public class NutritionFacts { 


// Parameters initialized to default values (if any) 
private int servingSize =-1; // Required; no default value 


private int servings =-1; // 
private int calories = 0; 
private int fat = 0; 
private int sodium = 0; 


private int carbohydrate = 0; 


public NutritionFacts() { } 


// Setters 

public void setServingSize(int val) { servingSize = val; } 
public void setServings(int val) { servings = val; } 
public void setCalories(int val) { calories = val; } 
public void setFat(int val) { fat = val; } 

public void setSodium(int val) { sodium = val; } 


j public void setCarbohydrate(int val) { carbohydrate = val; } 

这 种 模式 弥补 了 重合 构造 器 模式 的 不 足 。 说 得 明白 一 点 ， 就 是 创建 实例 很 容易 ， 这 样 产生 
的 代码 读 起 来 也 很 容易 : 

NutritionFacts cocaCola = new NutritionFacts(); 

cocaCola.setServingSize(24) ; 

cocaCola.setServings(8); 

cocaCola.setCalories(10@) ; 


cocaCola.setSodium(35); 
cocaCola.setCarbohydrate(27) ; 


遗憾 的 是 ，JavaBeans 模 式 自身 有 着 很 严重 的 缺点 。 因 为 构造 过 程 被 分 到 了 几 个 调用 中 ， 
在 构造 过 程 中 JavaBean 可 能 处 于 不 一 致 的 状态 。 类 无 法 仅仅 通过 检验 构造 器 参数 的 有 效 性 来 


保证 一 致 性 。 试 图 使 用 处 于 不 一 致 状态 的 对 象 ， 将 会 导致 失败 ， 这 种 失败 与 包含 错误 的 代码 
大 相 径 庭 ， 因 此 它 调试 起 来 十 分 困难 。 与 此 相关 的 另 一 点 不 足 在 于 ，JayaBeans 模 式 阻止 了 把 
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类 做 成 不 可 变 的 可 能 ( 见 第 15 条 ) ， 这 就 需要 程序 员 付出 额外 的 努力 来 确保 它 的 线程 安全 。 


当 对 象 的 构造 完成 ， 并 且 不 允许 在 解冻 之 前 使 用 时 ， 通 过 手工 “冻结 ”对 象 ， 可 以 弥补 这 
些 不 足 ， 但 是 这 种 方式 十 分 条 拙 ， 在 实践 中 很 少 使 用 。 此 外 ， 它 甚至 会 在 运行 时 导致 错误 ， 
因为 编译 器 无 法 确保 程序 员 会 在 使 用 之 前 先 在 对 象 上 调用 freeze 方 法 。 


幸运 的 是 ， 还 有 第 三 种 替代 方法 ， 既 能 保证 像 重叠 构造 器 模式 那样 的 安全 性 ， 也 能 保证 像 
JavaBeans 模 式 那么 好 的 的 可 读 性 。 这 就 是 Builder 模 式 [Gamma95，p.97] 的 一 种 形式 。 不 直接 
生成 想 要 的 对 象 ， 而 是 让 客户 端 利用 所 有 必要 的 参数 调用 构造 器 (或 者 静态 工厂 ) ， 得 到 一 
builder 对 象 。 然 后 客户 端 在 builder 对 象 上 调用 类 似 于 setter 的 方法 ,来 设置 每 个 相关 的 可 选 参 
数 。 最 后 ， 客 户 端 调用 无 参 的 build 方 法 来 生成 不 可 变 的 对 象 。 这 个 builder 是 它 构建 的 类 的 静 
态 成 员 类 ( 见 第 22 条 )。 下 面 就 是 它 的 示例 : 


// Builder Pattern 

public class NutritionFacts { 
private final int servingSize; 
private final int servings; 
private final int calories; 
private final int fat; 
private final int sodium; 
private final int carbohydrate; 


public static class Builder { 
// Required parameters 
private final int servingSize; 
private final int servings; 


// Optional parameters - initialized to default values 
private int calories = 0; 人 
private int fat = 0; 

private int carbohydrate = 0; 

private int sodium = 0; 


public Builder(int servingSize, int servings) { 
this.servingSize = servingSize; 
this.servings = servings; 

} 


public Builder calories(int val) 

{ calories = val; return this; } 
public Builder fat(int val) 

{ fat = val; return this; } 
public Builder carbohydrate(int val) 

{ carbohydrate = val; return this; } 
public Builder sodium(int val) 

{ sodium = val; return this; } 


public NutritionFacts build() { 
return new NutritionFacts(this); 


} 


private NutritionFacts(Builder builder) { 
servingSize = builder.servingSize; 
servings = builder.servings; 
calories = builder.calories; 
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fat = builder.fat; 
sodium = builder.sodium; 
carbohydrate = builder.carbohydrate; 
} 
} 
注意 NutritionFacts 是 不 可 变 的 ， 所 有 的 默认 参数 值 都 单独 放 在 一 个 地 方 。builder 的 setter 
方法 返回 builder 本 身 ， 以 便 可 以 把 调用 链接 起 来 。 下 面 就 是 客户 端 代码 : 


NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8). 
calories(100) .sodium(35).carbohydrate(27).buildQ; 


“这 样 的 客户 端 代码 很 容易 编写 ， 更 为 重要 的 是 ， 易 于 阅读 。builder 模 式 模拟 了 具名 的 可 
选 参 数 ， 就 像 Ada 和 Python 中 的 一 样 。 


builder 像 个 构造 器 一 样 ， 可 以 对 其 参数 强加 约束 条 件 。build 方 法 可 以 检验 这 些 约束 条 件 。 
将 参数 从 builder 拷 贝 到 对 象 中 之 后 ， 并 在 对 象 域 而 不 是 builder 域 ( 见 第 39 条 ) 中 对 它们 进行 检 
验 ， 这 一 点 很 重要 。 如 果 违 反 了 任何 约束 条 件 ，build 方 法 就 应 该 抛 出 IlegalStateException ( 见 
第 60 条 )。 异 常 的 详细 信息 应 该 显示 出 违反 了 哪个 约束 条 件 ( 见 第 63 条 )。 


对 多 个 参数 强加 约束 条 件 的 另 一 种 方法 是 ， 用 多 个 setter 方 法 对 某 个 约束 条 件 必 须 持 有 的 所 有 
参数 进行 检查 。 如 果 该 约束 条 件 没有 得 到 满足 ，setter 方 法 就 会 揭 出 IllegalArgumentException。 这 
有 个 好 处 ， 就 是 一 旦 传递 了 无 效 的 参数 ， 立 即 就 会 发 现 约束 条 件 失败 ， 而 不 是 等 着 调用 build 方 法 。 


与 构造 器 相 比 ，builder 的 微 略 优势 在 于 ，builder 可 以 有 多 个 可 变 (varargs) 参数 。 构 造 
器 就 像 方法 一 样 ， 只 能 有 一 个 可 变 参 数 。 因 为 builder 利 用 单独 的 方法 来 设置 每 个 参数 ， 你 想 
要 多 少 个 可 变 参数 ， 它 们 就 可 以 有 多 少 个 ， 直 到 每 个 setter 方 法 都 有 一 个 可 变 参数 。 


Builder 模 式 十 分 灵活 ， 可 以 利用 单个 builder 构 建 多 个 对 象 。builder 的 参数 可 以 在 创建 对 
象 期 间 进行 调整 ， 也 可 以 随 着 不 同 的 对 象 而 改变 。builder 可 以 自动 填充 某 些 域 ， 例 如 每 次 创 
建 对 象 时 自动 增加 序列 号 。 


设置 了 参数 的 builder 生 成 了 一 个 很 好 的 抽象 工厂 (Abstract Factory) [Gamma95,. p.87], 
换 句 话说 ， 客 户 端 可 以 将 这 样 一 个 builder 传 给 方法 ， 使 该 方法 能 够 为 客户 端 创建 一 个 或 者 多 个 
对 象 。 要 使 用 这 种 用 法 ， 需 要 有 个 类 型 来 表示 builder。 如 果 使 用 的 是 发 行 版 本 1.5 或 者 更 新 的 版 
本 ， 只 要 一 个 泛 型 ( 见 第 26 条 ) 就 能 满足 所 有 的 builder， 无 论 它们 在 构建 哪 种 类 型 的 对 象 ; 

// A builder for objects of type T 


public interface Builder<T> { 
public T buildQ; 


注意 ， 可 以 声明 NutritionFacts.Builder 类 来 实现 Builder<NutritionFacts>。 
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带 有 Builder 实 例 的 方法 通常 利用 有 限制 的 通配符 类 型 (bounded wildcard type, WL 4284) 
来 约束 构建 器 的 类 型 参数 。 例 如 ， 下 面 就 是 构建 每 个 节点 的 方法 ， 它 利用 一 个 客户 端 提供 的 
Builder 实 例 来 构建 树 : 


Tree buildTree(Builder<? extends Node> nodeBuilder) { ... } 


Java 中 传统 的 抽象 工厂 实现 是 Class 对 象 ， 用 newInstance 方 法 充当 build 方 法 的 一 部 分 。 这 
种 用 法 隐 售 着 许多 问题 。newJInstance 方 法 总 是 企图 调用 类 的 无 参 构造 器 ， 这 个 构造 器 甚至 可 
能 根本 不 存在 。 如 果 类 没有 可 以 访问 的 无 参 构造 器 ， 你 也 不 会 收 到 编译 时 错误 。 相 反 ， 客 户 
端 代码 必须 在 运行 时 处 理 InstantiationException 或 者 IllegalAccessException， 这 样 既 不 雅 观 也 
不 方便 。newInstance 方 法 还 会 传播 由 无 参 构造 器 抛 出 的 任何 异常 ， 即 使 newInstance 缺 乏 相应 
的 throws 子 句 。 换 名 话说 ，Class.newInstance 破 坏 了 编译 时 的 异常 检查 。 上 面 讲 过 的 Builder 
接口 弥补 了 这 些 不 足 。 


Builder 模 式 的 确 也 有 它 自身 的 不 足 。 为 了 创建 对 象 ， 必 须 先 创建 它 的 构建 器 。 虽 然 创 建 
构建 器 的 开销 在 实践 中 可 能 不 那么 明显 ， 但 是 在 某 些 十 分 注重 性 能 的 情况 下 ， 可 能 就 成 问题 
了 。Bnuilder 模 式 还 比重 登 构造 器 模式 更 加 宛 长 ， 因 此 它 只 在 有 很 多 参数 的 时 候 才 使 用 ， 比 如 4 
个 或 者 更 多 个 参数 。 但 是 记 住 ， 将 来 你 可 能 需要 添加 参数 。 如 果 一 开始 就 使 用 构造 器 或 者 静 
态 工厂 ， 等 到 类 需要 多 个 参数 时 才 添 加 构建 器 ， 就 会 无 法 控制 ， 那 些 过 时 的 构造 器 或 者 静态 
工厂 显得 十 分 不 协调 。 因 此 ， 通 常 最 好 一 开始 就 使 用 构建 器 。 


简 而 言 之 ， 如 果 类 的 构造 器 或 者 静态 工厂 中 具有 多 个 参数 ， 设 计 这 种 类 时 ，Builder 模 式 就 
是 种 不 错 的 选择 ， 特 别 是 当 大 多 数 参 数 都 是 可 选 的 时 候 。 与 使 用 传统 的 重 琶 构造 器 模式 相 比 ， 
使 用 Builder 模 式 的 客户 端 代码 将 更 易于 阅读 和 编写 ， 构 建 器 也 比 JavaBeans 更 加 安全 。 





Singleton 指 仅仅 被 实例 化 一 次 的 类 [Gamma95, p. 127]。Singleton 通 常 被 用 来 代表 那些 本 
质 上 唯一 的 系统 组 件 ， 比 如 窗口 管理 器 或 者 文件 系统 。 使 类 成 为 Singleton 会 使 它 的 客户 端 测 
试 变 得 十 分 困难 ， 因 为 无 法 给 Singleton 替 换 模拟 实现 ， 除 非 它 实现 一 个 充当 其 类 型 的 接口 。 


在 Java 1.5 发 行 版 本 之 前 ， 实 现 Singleton 有 两 种 方法 。 这 两 种 方法 都 要 把 构造 器 保持 为 私 
有 的 ， 并 导出 公有 的 静态 成 员 ， 以 便 允 许 客 户 端 能 够 访问 该 类 的 唯一 实例 。 在 第 一 种 方法 中 ， 
公有 静态 成 员 是 个 final 域 : 
// Singleton with public final field 
public class Elvis { 
public static final Elvis INSTANCE = new Elvis(); 
private Elvis() { ... } 


public void leaveTheBuilding() { ... } 


私有 构造 器 仅 被 调用 一 次 ， 用 来 实例 化 公有 的 静态 final 域 Elvis.INSTANCE。 由 于 缺少 公 
有 的 或 者 受 保护 的 构造 器 ， 所 以 保证 了 Elvis 的 全 局 唯一 性 : 一 旦 Elvis 类 被 实例 化 ， 只 会 存在 
一 个 Elvis 实 例 ， 不 多 也 不 少 。 客 户 端的 任何 行为 都 不 会 改变 这 一 点 ， 但 要 提醒 一 点 : 享有 特 
权 的 客户 端 可 以 借助 AccessibleObject.setAccessible 方 法 ， 通 过 反射 机 制 ( 见 第 53 条 ) 调用 私 
有 构造 器 。 如 果 需 要 抵御 这 种 攻击 ， 可 以 修改 构造 器 ， 让 它 在 被 要 求 创建 第 二 个 实例 的 时 候 
抛 出 异常 。 


在 实现 Singleton 的 第 二 种 方法 中 ， 公 有 的 成 员 是 个 静态 工厂 方法 : 


// Singleton with static factory 

public class Elvis { 
private static final Elvis INSTANCE = new Elvis(); 
private Elvis) { ... } 
public static Elvis getInstance() { return INSTANCE; } 


public void leaveTheBuilding() { ... } 


对 于 静态 方法 Elvis.getInstance 的 所 有 调用 ， 都 会 返回 同一 个 对 象 引 用 ， 所 以 ， 永 远 不 会 
创建 其 他 的 Elvis 实 例 (上 述 提醒 依然 适用 )。 


公有 域 方法 的 主要 好 处 在 于 , 组 成 类 的 成 员 的 声明 很 清楚 地 表明 了 这 个 类 是 一 个 Singleton: 
公有 的 静态 域 是 final 的 ， 所 以 该 域 将 总 是 包含 相同 的 对 象 引 用 。 公 有 域 方 法 在 性 能 上 不 再 有 
任何 优势 : 现代 的 JVM (Java 虚拟 机 ，Java Virtual Machine) 实现 几乎 都 能 够 将 静态 工厂 方 
法 的 调用 内 联 化 。 
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工厂 方法 的 优势 之 一 在 于 ， 它 提供 了 灵活 性 : 在 不 改变 其 API 的 前 提 下 ， 我 们 可 以 改变 该 
类 是 否 应 该 为 Singleton 的 想法 。 工 厂 方法 返回 该 类 的 唯一 实例 ， 但 是 ， 它 可 以 很 容易 被 修改 ， 
比如 改 成 为 每 个 调用 该 方法 的 线程 返回 一 个 唯一 的 实例 。 第 二 个 优势 与 泛 型 ( 见 第 27 条 ) 有 
关 。 这 些 优势 之 间 通常 都 不 相关 ，public 域 (public-field) 的 方法 比较 简单 。 


ALESSI cA AS HOR ET FERD, Seriza), CRAN 
章 )， 仅 仅 在 声明 中 加 上 “implements Serializable” 是 不 够 的 。 为 了 维护 并 保证 Singleton， 必 
须 声 明 所 有 实例 域 都 是 瞬时 (transient) 的 ， 并 提供 一 个 readResolve 方 法 ( 见 第 77 条 )。 否 则 ， 
每 次 反 序列 化 一 个 序列 化 的 实例 时 ， 都 会 创建 一 个 新 的 实例 ， 比 如 说 ， 在 我 们 的 例子 中 ， 会 
导致 “假冒 的 Elvis" 。 为 了 防止 这 种 情况 ， ‘So ee oe 

// readResolve method to preserve singleton property 

private Object readResolve() { 

// Return the one true Elvis and let the garbage collector 
// take care of the Elvis impersonator. ` 


return INSTANCE; 
} 


从 Java 1.5 发 行 版 本 起 ， 实 现 Singleton 还 有 第 三 种 方法 。 只 需 编写 一 个 包含 单个 元 素 的 枚 
举 类 型 : 
// Enum singleton - the preferred approach 
public enum Elvis { 
INSTANCE; 


public void leaveTheBuilding() { ... } 


这 种 方法 在 功能 上 与 公有 域 方 法 相近 ， 但 是 它 更 加 简洁 ， 无 偿 地 提供 了 序列 化 机 制 ， 绝 对 
防止 多 次 实例 化 ， 即 使 是 在 面 对 复 杂 的 序列 化 或 者 反射 攻击 的 时 候 。 虽 然 这 种 方法 还 没有 广 
证 采用 ， 但 是 单元 素 的 枚 举 类 型 已 经 成 为 实现 Singleton 的 最 佳 方法 。 





有 时 候 ， 你 可 能 需要 编写 只 包含 静态 方法 和 静态 域 的 类 。 这 些 类 的 名 声 很 不 好 ， 因 为 有 些 
人 在 面向 对 象 的 语言 中 滥用 这 样 的 类 来 编写 过 程 化 的 程序 。 尽 管 如 此 ， 它 们 也 确实 有 它们 特 
有 的 用 处 。 我 们 可 以 利用 这 种 类 ， 以 java.lang.Math 或 者 java.util.Arrays 的 方式 ， 把 基本 类 型 
的 值 或 者 数组 类 型 上 的 相关 方法 组 织 起 来 。 我 们 也 可 以 通过 java.util.Collections 的 方式 ， 把 实 
现 特 定 接口 的 对 象 上 的 静态 方法 (包括 工厂 方法 ， 见 第 1 条 ) 组 织 起 来 。 最 后 ， 还 可 以 利用 这 
种 类 把 final 类 上 的 方法 组 织 起 来 ， 以 取代 扩展 该 类 的 做 法 。 


这 样 的 工具 类 (utility class) 不 希望 被 实例 化 ， 实例 对 它 没有 任何 意义 。 然 而 ， 在 缺少 显 
式 构造 器 的 情况 下 ， 编 译 器 会 自动 提供 一 个 公有 的 、 无 参 的 缺 省 构造 器 (default constructor), 
对 于 用 户 而 言 ， 这 个 构造 器 与 其 他 的 构造 器 没有 任何 区 别 。 在 已 发 行 的 API 中 常常 可 以 看 到 一 
些 被 无 意识 地 实例 化 的 类 。 


企图 通过 将 类 做 成 抽象 类 来 强制 该 类 不 可 被 实例 化 ， 这 是 行 不 通 的 。 该 类 可 以 被 子 类 化 ， 
并 且 该 子 类 也 可 以 被 实例 化 。 这 样 做 甚至 会 误导 用 户 ， 以 为 这 种 类 是 专门 为 了 继承 而 设计 的 
( 见 第 17 条 ) 。 然 而 ， 有 一 些 简单 的 习惯 用 法 可 以 确保 类 不 可 被 实例 化 。 由 于 只 有 当 类 不 包含 
显 式 的 构造 器 时 ， 编 译 器 才 会 生成 缺 省 的 构造 器 ， 因 此 我 们 只 要 让 这 个 类 包含 私有 构造 器 ， 
它 就 不 能 被 实例 化 了 : 

// Noninstantiable utility class 

public class UtilityClass { , 

// Suppress default constructor for noninstantiability 
private UtilityClass() { 
throw new AssertionError(); 
. // Remainder omitted 

} » 

由 于 显 式 的 构造 器 是 私有 的 ， 所 以 不 可 以 在 该 类 的 外 部 访问 它 。AssertionError 不 是 必需 
的 ， 但 是 它 可 以 避免 不 小 心 在 类 的 内 部 调用 构造 器 。 它 保证 该 类 在 任何 情况 下 都 不 会 被 实例 
化 。 这 种 习惯 用 法 有 点 违背 直觉 ， 好 像 构 造 器 就 是 专门 设计 成 不 能 被 调用 一 样 。 因 此 ， 了 明智 
的 做 法 就 是 在 代码 中 增加 一 条 注释 ， 如 上 所 示 。 


这 种 习惯 用 法 也 有 副作用 ， 它 使 得 一 个 类 不 能 被 子 类 化 。 所 有 的 构造 器 都 必须 显 式 或 隐 式 
地 调用 超 类 (superclass) 构造 器 ， 在 这 种 情形 下 ， 子 类 就 没有 可 访问 的 超 类 构造 器 可 调用 了 。 
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一 般 来 说 ， 最 好 能 重用 对 象 而 不 是 在 每 次 需要 的 时 候 就 创建 一 个 相同 功能 的 新 对 象 。 重 用 
方式 既 快 速 ， 又 流行 。 如 果 对 象 是 不 可 变 的 (immutable) ( 见 第 15 条 ) ， 它 就 始终 可 以 被 重用 。 


作为 一 个 极端 的 反面 例子 ， 考 虑 下 面 的 语句 : 


String s = new String("stringette"); // DON'T DO THIS! 


该 语句 每 次 被 执行 的 时 候 都 创建 一 个 新 的 String 实 例 ， 但 是 这 些 创建 对 象 的 动作 全 都 是 不 
必要 的 。 传 递 给 String 构 造 器 的 参数 (“stringette”) 本 身 就 是 一 个 String 实 例 ， 功 能 方面 等 同 
于 构造 器 创建 的 所 有 对 象 。 如 果 这 种 用 法 是 在 一 个 循环 中 ， 或 者 是 在 一 个 被 频繁 调用 的 方法 
中 ， 就 会 创建 出 成 千 上 万 不 必要 的 String 实 例 。 


改进 后 的 版 本 如 下 所 示 : 
String s = "stringette"; 


这 个 版 本 只 用 了 一 个 String 实 例 ， 而 不 是 每 次 执行 的 时 候 都 创建 一 个 新 的 实例 。 而 且 ， 它 
可 以 保证 ， 对 于 所 有 在 同一 台 虚 拟 机 中 运行 的 代码 ， 只 要 它们 包含 相同 的 字符 串 字 面 常量 ， 
该 对 象 就 会 被 重用 [JLS, 3.10.5], 


对 于 同时 提供 了 静态 工厂 方法 ( 见 第 1 条 ) 和 构造 器 的 不 可 变 类 ， 通 常 可 以 使 用 静态 工厂 
方法 而 不 是 构造 器 ， 以 避免 创建 不 必要 的 对 象 。 例 如 ， 静 态 工厂 方法 Boolean.valueOf (String) 
几乎 总 是 优先 于 构造 器 Boolean(String)。 构 造 器 在 每 次 被 调用 的 时 候 都 会 创建 一 个 新 的 对 象 ， 
而 静态 工厂 方法 则 从 来 不 要 求 这 样 做 ,实际 上 也 不 会 这 样 做 。 


除了 重用 不 可 变 的 对 象 之 外 ， 也 可 以 重用 那些 已 知 不 会 被 修改 的 可 变 对 象 。 下 面 是 一 个 比 
较 微 妙 、 也 比较 常见 的 反面 例子 ， 其 中 涉及 可 变 的 Date 对 象 ， 它 们 的 值 一 旦 计算 出 来 之 后 就 
不 再 变化 。 这 个 类 建立 了 一 个 模型 : 其 中 有 一 个 人 ， 并 有 一 个 isBabyBoomer 方 法 ， 用 来 检验 
这 个 人 是 否 为 一 个 “baby boomer (生育 高 峰 期 出 生 的 小 孩 ) ”， 换 句 话 说， 就 是 检验 这 个 人 是 
否 出 生 于 1946 年 至 1964 年 期 间 。 

public class Person { 

private final Date birthDate; 
// Other fields, methods, and constructor omitted 
// DON'T DO THIS! 
public boolean isBabyBoomer() { 
// Unnecessary allocation of expensive object 


Calendar gmtCal = 
Calendar .getInstance(TimeZone.getTimeZone("GMT")) ; 
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gmtCal.set(1946, Calendar.JANUARY, 1, @, ©, 0); 
Date boomStart = gmtCal.getTime(); A 
gmtCal.set(1965, Calendar.JANUARY, 1, @, ©, @); 
Date boomEnd = gmtCal.getTime(); 

return birthDate.compareTo(boomStart) >= 0 & 

birthDate.compareTo(boomEnd) < 0; 
} 
} 


isBabyBoomer 每 次 被 调用 的 时 候 , 都 会 新 建 一 个 Calendar、 一 个 TimeZone 和 两 个 Date 实 例 ， 
这 是 不 必要 的 。 下 面 的 版 本 用 一 个 静态 的 初始 化 器 (initializer), ， 避 免 了 这 种 效率 低下 的 情况 ， 
class Person { 
private final Date birthDate; 
// Other fields, methods, and constructor omitted 


[aw 

* The starting and ending dates of the baby boom. 

*/ 

private static final Date BOOM_START; 

private static final Date BOOM_END; 

static { 
Calendar gmtCal = a 

Calendar .getInstance(TimeZone.getTimeZone("GMT")); 

gmtCal.set(1946, Calendar. JANUARY, 1, @, 0, 0) 
BOOM_START = gmtCal.getTime() ; 
gmtCal.set(1965, Calendar.JANUARY, 1, 0, ©, 9); 
BOOM_END = gmtCal.getTime(); 

} 

public boolean isBabyBoomer() { 
return birthDate.compareTo(BOOM_START) >= 0 && 

birthDate.compareTo(BOOM_END) < 0; 
} 
} 


改进 后 的 Person 类 只 在 初始 化 的 时 候 创 建 Calendar、TimeZone 和 Date 实 例 一 次 ， 而 不 是 在 
每 次 调用 isBabyBoomer 的 时 候 都 创建 这 些 实例 。 如 果 isBabyBoomer 方 法 被 频繁 地 调用 ， 这 种 
方法 将 会 显著 地 提高 性 能 。 在 我 的 机 器 上 ， 每 调用 一 千 万 次 ， 原 来 的 版 本 需要 32 000ms ， 而 
改进 后 的 版 本 只 需 130ms， 大 约 快 了 250 倍 。 除 了 提高 性 能 之 外 ， 代 码 的 含义 也 更 加 清晰 了 。 
把 boomStart 和 boomEnd 从 局 部 变量 改 为 final 静 态 域 ， 这 些 日 期 显然 是 被 作为 常量 对 待 ， 从 而 
使 得 代码 更 易于 理解 。 但 是 ， 这 种 优化 带 来 的 效果 并 不 总 是 那么 明显 ， 因 为 Calendar 实 例 的 创 
建 代价 特别 昂贵 。 


如 果 改 进 后 的 Person 类 被 初始 化 了 ， 它 的 isBabyBoomer 方 法 却 永远 不 会 被 调用 ， 那 就 没有 
必要 初始 化 BOOM_START 和 BOOM_END 域 。 通 过 延迟 初始 化 (lazily initializing) ( 见 第 71 
条 )， 即 把 对 这 些 域 的 初始 化 延迟 到 isBabyBoomer 方 法 第 一 次 被 调用 的 时 候 进 行 ， 则 有 可 能 消 
除 这 些 不 必要 的 初始 化 工作 ， 但 是 不 建议 这 样 做 。 正 如 延迟 初始 化 中 常见 的 情况 一 样 ， 这 样 做 
会 使 方法 的 实现 更 加 复杂 ， 从 而 无 法 将 性 能 显著 提高 到 超过 已 经 达到 的 水 平 ( 见 第 55 条 ) 。 
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在 本 条 目前 面 的 例子 中 ， 所 讨论 到 的 对 象 显然 都 是 能 够 被 重用 的 ， 因 为 它们 被 初始 化 之 后 
不 会 再 改变 。 其 他 有 些 情 形 则 并 不 总 是 这 么 明显 了 。 考 虑 适配器 (adapter) 的 情形 [Gamma95， 
P- 139]， 有 时 也 叫做 视图 (view)。 适 配器 是 指 这 样 一 个 对 象 ; 它 把 功能 委托 给 一 个 后 备 对 象 
(backing object) ， 从 而 为 后 备 对 象 提供 一 个 可 以 替代 的 接口 。 由 于 适配器 除了 后 备 对 象 之 
外 ， 没 有 其 他 的 状态 信息 ， 所 以 针对 某 个 给 定 对 象 的 特定 适配器 而 言 ， 它 不 需要 创建 多 个 适 本 
器 实例 。 


例如 ，Map 接 口 的 keySet 方 法 返回 该 Map 对 象 的 Set 视 图 ,其 中 包含 该 Map 中 所 有 的 键 
(key)。 粗 看 起 来 ， 好 像 每 次 调用 keySet 都 应 该 创建 一 个 新 的 Set 实 例 ， 但 是 ， 对 于 一 个 给 定 的 
Map 对 象 ， 实 际 上 每 次 调用 keySet 都 返回 同样 的 Set 实 例 。 虽然 被 返回 的 Set 实 例 一 般 是 可 改变 
的 ， 但 是 所 有 返回 的 对 象 在 功能 上 是 等 同 的 : 当 其 中 一 个 返回 对 象 发 生变 化 的 时 候 ， 所 有 其 
他 的 返回 对 象 也 要 发 生变 化 ， 因 为 它们 是 由 同一 个 Map 实 例 支撑 的 。 虽然 创建 keySet 视 图 对 象 
的 多 个 实例 并 无 害处 ， 却 也 是 没有 必要 的 。 


在 Java 1.5 发 行 版 本 中 ， 有 一 种 创建 多 余 对 象 的 新 方法 ， 称 作 自 动 装 箱 (autoboxing) , 
它 允 许 程序 员 将 基本 类 型 和 装 箱 基本 类 型 (Boxed Primitive Type) 混用 ， 按 需 要 自动 装 箱 和 
拆 箱 。 自动 装 箱 使 得 基本 类 型 和 装 箱 基本 类 型 之 间 的 差别 变 得 模糊 起 来 ， 但 是 并 没有 完全 消 
除 。 它 们 在 语义 上 还 有 着 微妙 的 差别 ， 在 性 能 上 也 有 着 比较 明显 的 差别 ( 见 第 49 条 )。 考 虑 下 
面 的 程序 ， 它 计算 所 有 int 正 值 的 总 和 。 为 此 ， 程 序 必须 使 用 long 算 法 ， 因 为 int 不 够 大 ， 无 法 
容纳 所 有 int 正 值 的 总 和 : 
// Hideously slow program! Can you spot the object creation? 
public static void main(String[] args) { 
Long sum = QL; 
for (long i = 0; i < Integer.MAX_VALUE; i++) { 


sum += i; 


System.out.printIn(sum) ; 


这 段 程序 算出 的 答案 是 正确 的 ， 但 是 比 实际 情况 要 更 慢 一 些 ， 只 因为 打 错 了 一 个 字符 ， 恋 
量 sum 被 声明 成 Long 而 不 是 long ， 意 味 着 程序 构造 了 大 约 2 个 多 余 的 Long 实 例 (大 约 每 次 往 
Long sum 中 增加 long 时 构造 一 个 实例 ) 。 将 sum 的 声明 从 Long 改 成 Iong， 在 我 的 机 器 上 使 运行 
时 间 从 43 秒 减少 到 了 6.8 秒 。 结 论 很 明显 : 要 优先 使 用 基本 类 型 而 不 是 装 箱 基本 类 型 ， 要 当心 
无 意识 的 自动 装 箱 。 


不 要 错误 地 认为 本 条 目 所 介绍 的 内 容 暗示 着 “创建 对 象 的 代价 非常 昂贵 ， 我 们 应 该 要 尽 可 
能 地 避免 创建 对 象 "。 相 反 ， 由 于 小 对 象 的 构造 器 只 做 很 少量 的 显 式 工作 ， 所 以 ， 小 对 象 的 创 
建 和 回收 动作 是 非常 廉价 的 ， 特 别 是 在 现代 的 JVM 实 现 上 更 是 如 此 。 通 过 创建 附加 的 对 象 ， 
提升 程序 的 清晰 性 、 简 洁 性 和 功能 性 ， 这 通常 是 件 好 事 。 
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反之 ， 通 过 维护 自己 的 对 象 池 (object pool) 来 避免 创建 对 象 并 不 是 一 种 好 的 做 法 ， 除 非 
池 中 的 对 象 是 非常 重量 级 的 。 真 正 正确 使 用 对 象 池 的 典型 对 象 示 例 就 是 数据 库 连 接 池 。 建 立 
数据 库 连接 的 代价 是 非常 昂贵 的 ， 因 此 重用 这 些 对 象 非常 有 意义 。 而 且 ， 数 据 库 的 许可 可 能 
限制 你 只 能 使 用 一 定数 量 的 连接 。 但 是 ， 一 般 而 言 ， 维 护 自 己 的 对 象 池 必 定 会 把 代码 弄 得 很 
乱 ， 同 时 增加 内 存 占用 (footprint)， 并 且 还 会 损害 性 能 。 现 代 的 JVM 实 现 具有 高 度 优化 的 垃 
圾 回收 器 ， 其 性 能 很 容易 就 会 超过 轻 量 级 对 象 池 的 性 能 。 


与 本 条 目 对 应 的 是 第 39 条 中 有 关 “ 保 护 性 描 贝 (defensive copying)” 的 内 容 。 本 条 目 提 
及 “ 当 你 应 该 重用 现 有 对 象 的 时 候 ， 请 不 要 创建 新 的 对 象 ” ， 而 第 39 条 则 说 “ 当 你 应 该 创建 新 
对 象 的 时 候 ， 请 不 要 重用 现 有 的 对 象 "。 注 意 ,， 在 提倡 使 用 保护 性 拷贝 的 时 候 ， 因 重用 对 象 而 
付出 的 代价 要 远 远 大 于 因 创建 重复 对 象 而 付出 的 代价 。 必 要 时 如 果 没 能 实施 保护 性 拷贝 ， 将 
会 导致 潜在 的 错误 和 安全 漏洞 ， 而 不 必要 地 创建 对 象 则 只 会 影响 程序 的 风格 和 性 能 。 
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当 你 从 手工 管理 内 存 的 语言 《比如 C 或 C++) 转换 到 具有 垃圾 回收 功能 的 语言 的 时 候 ， 程 
序 员 的 工作 会 变 得 更 加 容易 ， 因 为 当 你 用 完了 对 象 之 后 ， 它 们 会 被 自动 回收 。 当 你 第 一 次 经 
历 对 象 回收 功能 的 时 候 ， 会 觉得 这 简直 有 点 不 可 思议 。 这 很 容易 给 你 留 下 这 样 的 印象 ， 认 为 
自己 不 再 需要 考虑 内 存 管理 的 事情 了 。 其 实 不 然 。 


考虑 下 面 这 个 简单 的 栈 实现 的 例子 : 


// Can you spot the “memory leak"? 
public class Stack { 
private Object[] elements; 
private int size = 0; 
private static final int DEFAULT_INITIAL_CAPACITY = 16; 


public Stack() { 
elements = new Object (DEFAULT_INITIAL_CAPACITY] ; 


} 

public void push(Object e) { 
ensureCapacity(); | 
elements[size++] = e; 

} 


public Object pop() { 
if (size == 0) 
throw new EmptyStackException(); 
return elements[--size]; 


[ae 

* Ensure space for at least one more element, roughly 

* doubling the capacity each time the array needs to grow. 
*/ 

private void ensureCapacity() { 

if (elements.length == size) 
elements = Arrays.copyOf(elements, 2 * size + 1); 
} 


} 


这 段 程序 〈 它 的 证 型 版 本 请 见 第 26 条 ) 中 并 没有 很 明显 的 错误 。 无 论 如 何 测试 ， 它 都 会 
成 功 地 通过 每 一 项 测试 ， 但 是 这 个 程序 中 隐藏 着 一 个 问题 。 不 严格 地 讲 ， 这 段 程序 有 一 个 
“内 存 泄漏 "， 随 着 垃圾 回收 器 活动 的 增加 ， 或 者 由 于 内 存 占用 的 不 断 增加 ， 程 序 性 能 的 降低 
会 逐渐 表现 出 来 。 在 极端 的 情况 下 ， 这 种 内 存 泄漏 会 导致 磁盘 交换 (Disk Paging), HBr 
程序 失败 (OutOfMemoryError 错 误 ) ， 但 是 这 种 失败 情形 相对 比较 少见 。 


那么 ， 程 序 中 哪里 发 生 了 内 存 泄 漏 呢 ? 如 果 一 个 栈 先 是 增长 ， 然 后 再 收缩 ， 那 么 ， 从 栈 中 
弹出 来 的 对 象 将 不 会 被 当 作 垃圾 回收 ， 即 使 使 用 栈 的 程序 不 再 引用 这 些 对 象 ， 它 们 也 不 会 被 
回收 。 这 是 因为 ， 栈 内 部 维护 着 对 这 些 对 象 的 过 期 引用 (obsolete reference)。 所 谓 的 过 期 引 
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用 ， 是 指 永远 也 不 会 再 被 解除 的 引用 。 在 本 例 中 ， 凡 是 在 elements 数 组 的 “活动 部 分 (active 
portion) ”之 外 的 任何 引用 都 是 过 期 的 。 活 动 部 分 是 指 elements 中 下 标 小 于 size 的 那些 元 素 。 


在 支持 垃圾 回收 的 语言 中 ， 内 存 泄漏 是 很 隐蔽 的 〈 称 这 类 内 存 泄漏 为 “无 意识 的 对 象 保持 
(unintentional object retention) ”更 为 恰当 )。 如 果 一 个 对 象 引 用 被 无 意识 地 保留 起 来 了 ， 那 
么 ， 垃 圾 回收 机 制 不 仅 不 会 处 理 这 个 对 象 ， 而 且 也 不 会 处 理 被 这 个 对 象 所 引用 的 所 有 其 他 对 
象 。 即 使 只 有 少量 的 几 个 对 象 引用 被 无 意识 地 保留 下 来 ， 也 会 有 许 许多 多 的 对 象 被 排除 在 垃 
圾 回收 机 制 之 外 ， 从 而 对 性 能 造成 潜在 的 重大 影响 。 


这 类 问题 的 修复 方法 很 简单 : 一 旦 对 象 引用 已 经 过 期 ， 只 需 清空 这 些 引用 即 可 。 XFER 
例子 中 的 Stack 类 而 言 ， 只 要 一 个 单元 被 弹出 栈 ， 指 向 它 的 引用 就 过 期 了 。pop 方 靶 的 修订 版 
本 如 下 所 示 : 

public Object pop() { 

if (size == 0) 
throw new EmptyStackException() ; 
Object result = elements[--size]; 
elements[size] = null; // Eliminate obsolete reference 


return result; 
} 


清空 过 期 引用 的 另 一 个 好 处 是 ， 如 果 它 们 以 后 又 被 错误 地 解除 引用 ， 程 序 就 会 立即 抛 出 
NullPointerException 异 常 ， 而 不 是 悄悄 地 错误 运行 下 去 。 尽 快 地 检测 出 程序 中 的 错误 总 是 有 
益 的 。 


当 程 序 员 第 一 次 被 类 似 这 样 的 问题 困扰 的 时 候 ， 他 们 往往 会 过 分 小 心 : 对 于 每 一 个 对 象 引 
用 ,一 旦 程序 不 再 用 到 它 ， 就 把 它 清空 。 其 实 这 样 做 既 没 必要 ， 也 不 是 我 们 所 期 望 的 ， 因 为 
这 样 做 会 把 程序 代码 弄 得 很 乱 。 清 空 对 象 引用 应 该 是 一 种 例外 ,而 不 是 一 种 规范 行为 。 消 除 
过 期 引用 最 好 的 方法 是 让 包含 该 引用 的 变量 结束 其 生命 周期 。 如 果 你 是 在 最 紧凑 的 作用 域 范 
围 内 定义 每 一 个 变量 ( 见 第 45 条 ) ， 这 种 情形 就 会 自然 而 然 地 发 生 。 


那么 ， 何 时 应 该 清空 引用 呢 ? Stack 类 的 哪 方 面 特性 使 它 易 于 遭受 内 存 泄 漏 的 影响 呢 ? 简 
而 言 之 ， 问 题 在 于 ，Stack 类 自己 管理 内 存 (manage its own memory)。 存 储 池 (storage pool) 
包含 了 elements 数 组 (对象 引 用 单元 ， 而 不 是 对 象 本 身 ) 的 元 素 。 数 组 活动 区 域 ( 同 前 面 的 定 
X) 中 的 元 素 是 已 分 配 的 (allocated) ， 而 数组 其 余部 分 的 元 素 则 是 自由 的 (free)。 但 是 垃圾 
回收 器 并 不 知道 这 一 点 ;对 于 垃圾 回收 器 而 言 ，elements 数 组 中 的 所 有 对 象 引用 都 同等 有 效 。 
只 有 程序 员 知 道 数组 的 非 活动 部 分 是 不 重要 的 。 程 序 员 可 以 把 这 个 情况 告知 垃圾 回收 器 ， 做 
法 很 简单 : 一 旦 数组 元 素 变 成 了 非 活动 部 分 的 一 部 分 ， 程 序 员 就 手工 清空 这 些 数 组 元 素 。 


一 般 而 言 ， 只 要 类 是 自己 管理 内 存 ， 程 序 员 就 应 该 警惕 内 存 泄 漏 问题 。 一 旦 元 素 被 释放 掉 ， 
则 该 元 素 中 包含 的 任何 对 象 引用 都 应 该 被 清空 。 
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内 存 泄 漏 的 另 一 个 常见 来 源 是 缓存 。 一 旦 你 把 对 象 引 用 放 到 缓存 中 , 它 就 很 容易 被 遗忘 掉 ， 
从 而 使 得 它 不 再 有 用 之 后 很 长 一 段 时间 内 仍然 留 在 缓存 中 。 对 于 这 个 问题 ， 有 几 种 可 能 的 解 
决 方案 。 如 果 你 正好 要 实现 这 样 的 缓存 : 只 要 在 缓存 之 外 存在 对 某 个 项 的 键 的 引用 ， 该 项 就 有 
意义 ， 那么 就 可 以 用 WeakHashMap 代 表 缓 存 ， 当 缓存 中 的 项 过 期 之 后 ， 它 们 就 会 自动 被 删除 。 
记 住 只 有 当 所 要 的 缓存 项 的 生命 周期 是 由 该 键 的 外 部 引用 而 不 是 由 值 决 定时 ，WeakHashMap 
才 有 用 处 。 


更 为 常见 的 情形 则 是 ,“ 缓 存 项 的 生命 周期 是 否 有 意义 ”并 不 是 很 容易 确定 ， 随 着 时 间 的 
推移 ， 其 中 的 项 会 变 得 越 来 越 没 有 价值 。 在 这 种 情况 下 ， 缓 存 应 该 时 不 时 地 清除 掉 没 用 的 项 。 
这 项 清除 工作 可 以 由 一 个 后 台 线 程 (可 能 是 Timer 或 者 ScheduledThreadPoolExecutor) 来 完成 ， 
或 者 也 可 以 在 给 缓存 添加 新 条 目的 时 候 顺 便 进行 清理 。LinkedHashMap 类 利用 它 的 
removeEldestEntry 方 法 可 以 很 容易 地 实现 后 一 种 方案 。 对 于 更 加 复杂 的 缓存 ， 必 须 直 接 使 用 
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内 存 泄 漏 的 第 三 个 常见 来 源 是 监听 器 和 其 他 回调 。 如 果 你 实现 了 一 个 API， 客 户 端 在 这 个 
API 中 注册 回调 ， 却 没有 显 式 地 取消 注册 ， 那 么 除非 你 采取 某 些 动 作 ， 否 则 它们 就 会 积聚 。 确 保 
回调 立即 被 当 作 垃 圾 回收 的 最 佳 方法 是 只 保存 它们 的 弱 引 用 (weak reference), 例如， 只 将 它们 
保存 成 WeakHashMap 中 的 键 。 


由 于 内 存 泄漏 通常 不 会 表现 成 明显 的 失败 ， 所 以 它们 可 以 在 一 个 系统 中 存在 很 多 年 。 往 往 
只 有 通过 仔细 检查 代码 ， 或 者 借助 于 Heap 剖 析 工 具 (Heap Profiler) 才能 发 现 内 存 泄漏 问题 。 
因此 ， 如 果 能 够 在 内 存 泄 漏 发 生 之 前 就 知道 如 何 预测 此 类 问题 ， 并 阻止 它们 发 生 ， 那 是 最 好 
不 过 的 了 。 





终结 方法 (finalizer) 通常 是 不 可 预测 的 ， 也 是 很 危险 的 , 一般 情况 下 是 不 必要 的 。 使 用 
终结 方法 会 导致 行为 不 稳定 、 降 低 性 能 ， 以 及 可 移植 性 问题 。 当 然 ， 终 结 方法 也 有 其 可 用 之 
处 ， 我 们 将 在 本 条 目的 最 后 再 做 介绍 ; 但 是 根据 经 验 ， 应 该 避免 使 用 终结 方法 。 


C++ 的 程序 员 被 告知 “不 要 把 终结 方法 当 作 是 C++ 中 析 构 器 (destructors) 的 对 应 物 ”。 在 
C++ 中 ， 析 构 器 是 回收 一 个 对 象 所 占用 资源 的 常规 方法 ,是 构造 器 所 必需 的 对 应 物 。 在 Java 中 ， 
当 一 个 对 象 变 得 不 可 到 达 的 时 候 ， 垃 圾 回收 器 会 回收 与 该 对 象 相关 联 的 存储 空间 ， 并 不 需要 
程序 员 做 专门 的 工作 。C++ 的 析 构 器 也 可 以 被 用 来 回收 其 他 的 非 内 存 资源 。 而 在 Java 中 ， 一 般 
用 try-finally 块 来 完成 类 似 的 工作 。 


终结 方法 的 缺点 在 于 不 能 保证 会 被 及 时 地 执行 [JLS, 12.6]。 从 一 个 对 象 变 得 不 可 到 达 开 始 ， 
到 它 的 终结 方法 被 执行 ， 所 花费 的 这 段 时 间 是 任意 长 的 。 这 意味 着 ,注重 时 间 (time-critical) 
的 任务 不 应 该 由 终结 方法 来 完成 。 例 如 ， 用 终结 方法 来 关闭 已 经 打开 的 文件 ， 这 是 严重 错误 ， 
因为 打开 文件 的 描述 符 是 一 种 很 有 限 的 资源 。 由 于 JVM 会 延迟 执行 终结 方法 ， 所 以 大 量 的 文 
件 会 保留 在 打开 状态 ， 当 一 个 程序 再 不 能 打开 文件 的 时 候 ， 它 可 能 会 运行 失败 。 


及 时 地 执行 终结 方法 正 是 垃圾 回收 算法 的 一 个 主要 功能 ， 这 种 算法 在 不 同 的 JVM 实 现 中 
会 大 相 径 庭 。 如 果 程 序 依赖 于 终结 方法 被 执行 的 时 间 点 ， 那 么 这 个 程序 的 行为 在 不 同 的 JVM 
中 运行 的 表现 可 能 就 会 截然 不 同 。 一 个 程序 在 你 测试 用 的 JVM 平 台 上 运行 得 非常 好 ， 而 在 你 
最 重要 顾客 的 JVM 平 台 上 却 根本 无 法 运行 ， 这 是 完全 有 可 能 的 。 


延迟 终结 过 程 并 不 只 是 一 个 理论 问题 。 在 很 少见 的 情况 下 ， 为 类 提供 终结 方法 ， 可 能 会 随 
意 地 延迟 其 实例 的 回收 过 程 。 一 位 同事 最 近 在 调试 一 个 长 期 运行 的 GUI 应 用 程序 的 时 候 ， 该 应 
用 程序 莫名 其 妙 地 出 现 OutOfMemoryError 错 误 而 死 掉 。 分 析 表 明 ， 该 应 用 程序 死 掉 的 时 候 ， 
其 终结 方法 队列 中 有 数 千 个 图 形 对 象 正 在 等 待 被 终结 和 回收 。 遗 憾 的 是 ， 终 结 方法 线程 的 优 
先 级 比 该 应 用 程序 的 其 他 线程 的 要 低 得 多 ， 所 以 ， 图 形 对 象 的 终结 速度 达 不 到 它们 进入 队列 
的 速度 。Java 语 言 规范 并 不 保证 哪个 线程 将 会 执行 终结 方法 ,所 以 , 除了 不 使 用 终结 方法 之 外 ， 
并 没有 很 轻便 的 办 法 能 够 避免 这 样 的 问题 。 


Java 语 言 规范 不 仅 不 保证 终结 方法 会 被 及 时 地 执行 ， 而 且 根本 就 不 保证 它们 会 被 执行 。 当 
一 个 程序 终止 的 时 候 ， 某 些 已 经 无 法 访问 的 对 象 上 的 终结 方法 却 根本 没有 被 执行 ， 这 是 完全 
有 可 能 的 。 结 论 是 : 不 应 该 依赖 终 结 方法 来 更 新 重要 的 持久 状态 。 例 如 ， 依 赖 终结 方法 来 释 
放 共 享 资 源 (比如 数据 库 ) 上 的 永久 锁 ， 很 容易 让 整个 分 布 式 系统 垮 掉 。 


不 要 被 System.gc 和 System.runFinalization 这 两 个 方法 所 诱惑 ， 它 们 确实 增加 了 终结 方法 
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被 执行 的 机 会 ， 但 是 它们 并 不 保证 终结 方法 一 定 会 被 执行 。 唯 一 声称 保证 终结 方法 被 执行 的 
方法 是 System.runFinalizersOnExit， 以 及 它 臭 名 昭 著 的 挛 生 兄弟 Runtime.runFinalizersOnExit。 
这 两 个 方法 都 有 致命 的 缺陷 ， 已 经 被 废弃 了 [ThreadStop]。 


当 你 并 不 确定 是 否 应 该 避免 使 用 终结 方法 的 时 候 ， 这 里 还 有 一 种 值得 考虑 的 情形 : 如 果 未 
被 捕获 的 异常 在 终结 过 程 中 被 抛 出 来 ， 那 么 这 种 异常 可 以 被 忽略 ， 并 且 该 对 象 的 终结 过 程 也 
会 终止 [JLS, 12.6]。 未 被 捕获 的 异常 会 使 对 象 处 于 破坏 的 状态 (a corrupt state), ， 如 果 另 一 个 
线程 企图 使 用 这 种 被 破坏 的 对 象 ， 则 可 能 发 生 任何 不 确定 的 行为 。 正 常情 况 下 ， 未 被 捕获 的 
异常 将 会 使 线程 终止 ， 并 打印 出 栈 轨迹 (Stack Trace), 但 是 ,如 果 异 常 发 生 在 终结 方法 之 中 ， 
则 不 会 如 此 ， 甚 至 连 警告 都 不 会 打印 出 来 。 


还 有 一 点 ; 使 用 终结 方法 有 一 个 非常 严重 的 (Severe) 性 能 损失 。 在 我 的 机 器 上 ， 创 建 和 
销毁 一 个 简单 对 象 的 时 间 大 约 为 5.6ns。 增 加 一 个 终结 方法 使 时 间 增加 到 了 2 400ns。 换 句 话说 ， 
用 终结 方法 创建 和 销毁 对 象 慢 了 大 约 430 倍 。 


那么 ， 如 果 类 的 对 象 中 封装 的 资源 (例如 文件 或 者 线程 ) 确实 需要 终止 ， 应 该 怎么 做 才能 
不 用 编写 终结 方法 呢 ? 只 需 提供 一 个 显 式 的 终止 方法 ， 并 要 求 该 类 的 客户 端 在 每 个 实例 不 再 
有 用 的 时 候 调 用 这 个 方法 。 值 得 提 及 的 一 个 细节 是 ， 该 实例 必须 记录 下 自己 是 否 已 经 被 终止 
T: 显 式 的 终止 方法 必须 在 一 个 私有 域 中 记录 下 “该 对 象 已 经 不 再 有 效 ”"。 如 果 这 些 方法 是 在 
对 象 已 经 终止 之 后 被 调用 ， 其 他 的 方法 就 必须 检查 这 个 域 ， 并 抛 出 IllegalStateException 异 常 。 


显 式 终止 方法 的 典型 例子 是 InputStream、 OutputStream 和 java.sql.Connection 上 的 close 方 法 。 
另 一 个 例子 是 java.util.Timer 上 的 cancel 方 法 ， 它 执行 必要 的 状态 改变 ， 使 得 与 Timer 实 例 相 关联 
的 该 线程 温和 地 终止 自己 。java.awt 中 的 例子 还 包括 Graphics.dispose 和 Window.dispose。 这 些 方 
法 通常 由 于 性 能 不 好 而 不 被 人 们 关注 。 一 个 相关 的 方法 是 Image.flush， 它 会 释放 所 有 与 Image 实 
例 相 关联 的 资源 ， 但 是 该 实例 仍然 处 于 可 用 的 状态 ， 如 果 有 必要 的 话 ， 会 重新 分 配 资源 。 


显 式 的 终止 方法 通常 与 try-finally 结 构 结合 起 来 使 用 ， 以 确保 及 时 终止 。 在 finally 子 句 内 
部 调用 显 式 的 终止 方法 ， 可 以 保证 即使 在 使 用 对 象 的 时 候 有 异常 抛 出 ， 该 终止 方法 也 会 执行 : 

// try-finally block guarantees execution of termination method 

Foo foo = new Foo(...); 

try { 

// Do what must be done with foo 
} finally { 
i foo. terminate() ; // Explicit termination method 


那么 终结 方法 有 什么 好 处 呢 ? 它们 有 两 种 合法 用 途 。 第 一 种 用 途 是 ， 当 对 象 的 所 有 者 忘记 
调用 前 面 段落 中 建议 的 显 式 终止 方法 时 ， 终 结 方法 可 以 充当 “安全 网 (safety net)”. BARZ 
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样 做 并 不 能 保证 终结 方法 会 被 及 时 地 调用 ， 但 是 在 客户 端 无 法 通过 调用 显 式 的 终止 方法 来 正 
常 结束 操作 的 情况 下 (希望 这 种 情形 尽 可 能 地 少 发 生 ) ， 迟 一 点 释放 关键 资源 总 比 永远 不 释放 
要 好 。 但 是 如 果 终结 方法 发 现 资源 还 未 被 终止 ， 则 应 该 在 日 志 中 记录 一 条 警告 ， 因 为 这 表示 
客户 端 代码 中 的 一 个 Bug， 应 该 得 到 修复 。 如 果 你 正 考 虑 编写 这 样 的 安全 网 终结 方法 ， 就 要 认 
真 考虑 清楚 ， 这 种 额外 的 保护 是 否 值得 你 付出 这 份额 外 的 代价 。 


显 式 终止 方法 模式 的 示例 中 所 示 的 四 个 类 (FileInputStream、FileOutputStream、Timer 
和 Connection) ， 都 具有 终结 方法 ， 当 它们 的 终止 方法 未 能 被 调用 的 情况 下 ， 这 些 终结 方法 充 
当 了 安全 网 。 ` 


终结 方法 的 第 二 种 合理 用 途 与 对 象 的 本 地 对 等 体 (native peer) 有 关 。 本 地 对 等 体 是 一 
个 本 地 对 象 (native object)， 普 通 对 象 通过 本 地 方法 (native method) 委托 给 一 个 本 地 对 象 。 
因为 本 地 对 等 体 不 是 一 个 普通 对 象 ， 所 以 垃圾 回收 器 不 会 知道 它 ， 当 它 的 Java 对 等 体 被 回收 的 
时 候 ， 它 不 会 被 回收 。 在 本 地 对 等 体 并 不 拥有 关键 资源 的 前 提 下 ， 终 结 方法 正 是 执行 这 项 任 
务 最 合适 的 工具 。 如 果 本 地 对 等 体 拥有 必须 被 及 时 终止 的 资源 ， 那 么 该 类 就 应 该 具有 一 个 显 
式 的 终止 方法 , .如 前 所 述 。 终 止 方法 应 该 完成 所 有 必要 的 工作 以 便 释 放 关 键 的 资源 。 终 止 方 
法 可 以 是 本 地 方法 ， 或 者 它 也 可 以 调用 本 地 方法 。 


值得 注意 的 很 重要 一 点 是 ,“ 终 结 方法 链 (finalizer chaining)” 并 不 会 被 自动 执行 。 如 果 类 
(不 是 Object) 有 终结 方法 ， 并 且 子 类 覆盖 了 终结 方法 ， 子 类 的 终结 方法 就 必须 手工 调用 超 类 的 
终结 方法 。 你 应 该 在 一 个 try 块 中 终结 子 类 ， 并 在 相应 的 finally 块 中 调用 超 类 的 终结 方法 。 这 样 
做 可 以 保证 : 即使 子 类 的 终结 过 程 抛 出 异常 ， 超 类 的 终结 方法 也 会 得 到 执行 。 反 之 亦 然 。 代 码 
示例 如 下 。 注 意 这 个 示例 使 用 了 Override 注 解 (@Override)， 这 是 Java 1.5 发 行 版 本 将 它 增 加 到 
Java 平 台中 的 。 你 现在 可 以 不 管 Override 注 解 ， 或 者 到 第 36 条 查阅 一 下 它们 表示 什么 意思 : 

// Manual finalizer chaining 

@Override protected void finalize() throws Throwable { 

= // Finalize subclass state 
} finally { 
; super. finalizeQ; 


} 


如 果子 类 实现 者 覆盖 了 超 类 的 终结 方法 ， 但 是 忘 了 手工 调用 超 类 的 终结 方法 (或 者 有 意 先 
择 不 调用 超 类 的 终结 方法 ) ， 那 么 超 类 的 终结 方法 将 永远 也 不 会 被 调用 到 。 要 防范 这 样 粗 心 大 
意 或 者 恶意 的 子 类 是 有 可 能 的 ， 代 价 就 是 为 每 个 将 被 终结 的 对 象 创建 一 个 附加 的 对 象 。 不 是 
把 终结 方法 放 在 要 求 终结 处 理 的 类 中 ， 而 是 把 终结 方法 放 在 一 个 匿名 的 类 ( 见 第 22 条 ) 中 ， 
该 匿名 类 的 唯一 用 途 就 是 终结 它 的 外 围 实 例 (enclosing instance) 。 该 匿名 类 的 单个 实例 被 称 
为 终结 方法 宁 卫 者 (finalizer guardian) ， 外 围 类 的 每 个 实例 都 会 创建 这 样 一 个 守卫 者 。 外 围 
实例 在 它 的 私有 实例 域 中 保存 着 一 个 对 其 终结 方法 守卫 者 的 唯一 引用 ， 因 此 终结 方法 守卫 者 
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与 外 围 实例 可 以 同时 启动 终结 过 程 。 当 守卫 者 被 终结 的 时 候 ， 它 执行 外 围 实例 所 期 望 的 终结 
行为 ， 就 好 像 它 的 终结 方法 是 外 围 对 象 上 的 一 个 方法 一 样 : 


// Finalizer Guardian idiom 
public class Foo { 
// Sole purpose of this object is to finalize outer Foo object 
private final Object finalizerGuardian = new Object() { 
@Override protected void finalize() throws Throwable { 
... // Finalize outer Foo object 


. // Remainder omitted 


注意 ， 公 有 类 Foo 并 没有 终结 方法 《除了 它 从 Object 中 继承 了 一 个 无 关 紧要 的 之 外 ) ， 所 以 
子 类 的 终结 方法 是 否 调用 super.finalize 并 不 重要 。 对 于 每 一 个 带 有 终结 方法 的 非 final 公 有 类 ， 
都 应 该 考虑 使 用 这 种 方法 。 


总 之 , 除非 是 作为 安全 网 , 或 者 是 为 了 终止 非 关键 的 本 地 资源 , 否则 请 不 要 使 用 终结 方法 。 
在 这 些 很 少见 的 情况 下 ， 既 然 使 用 了 终结 方法 ， 就 要 记 住 调用 super.finalize。 如 果 用 终结 方法 
作为 安全 网 ， 要 记得 记录 终结 方法 的 非法 用 法 。 最 后 ， 如 果 需 要 把 终结 方法 与 公有 的 非 final 
类 关联 起 来 , 请 考虑 使 用 终结 方法 守卫 者 , 以 确保 即使 子 类 的 终结 方法 未 能 调用 super.finalize， 
该 终结 方法 也 会 被 执行 。 
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对 于 所 有 对 象 都 通用 的 方法 


尽管 Object 是 一 个 具体 类， 但 是 设计 它 主 要 是 为 了 扩展 。 它 所 有 的 非 final 方 法 (equals、 
hashCode、toString、clone 和 finalize) 都 有 明确 的 通用 约定 (general contract), 因为 它们 
被 设计 成 是 要 被 覆盖 (override) 的 。 任 何 一 个 类 ， 它 在 覆盖 这 些 方法 的 时 候 ， 都 有 责任 遵守 
这 些 通用 约定 ， 如果 不 能 做 到 这 一 点 ， 其 他 依赖 于 这 些 约定 的 类 (例如 HashMap 和 HashSet) 
就 无 法 结合 该 类 一 起 正常 运作 。 


本 章 将 讲述 何 时 以 及 如 何 覆 盖 这 些 非 final 的 Object 方 法 。 本 章 不 再 讨论 finalize 方 法 ， 因 
为 第 7 条 已 经 讨论 过 这 个 方法 了 。 而 Comparable.compareTo 虽 然 不 是 Object 方法 ， 但 是 本 章 也 
对 它 进 行 讨 论 ， 因 为 它 具 有 类 似 的 特征 。 





覆盖 equals 方 法 看 起 来 似乎 很 简单 ， 但 是 有 许多 覆盖 方式 会 导致 错误 ， 并且 后 果 非 常 严重 。 
最 容易 避免 这 类 问题 的 办 法 就 是 不 覆盖 equals 方 法 ， 在 这 种 情况 下 ， 类 的 每 个 实例 都 只 与 它 自 ~ 
身 相等 。 如 果 满 足 了 以 下 任何 一 个 条 件 ， 这 就 正 是 所 期 望 的 结果 : 


* 类 的 每 个 实例 本 质 上 都 是 唯一 的 。 对 于 代表 活动 实体 而 不 是 值 (value) 的 类 来 说 确实 如 
此 ， 例 如 Thread。Object 提 供 的 equals 实 现 对 于 这 些 类 来 说 正 是 正确 的 行为 。 


* 不 关心 类 是 否 提供 了 “逻辑 相等 (logical equality)” 的 测试 功能 。 例 如 ，java.util. 
Random 有 覆盖 了 equals， 以 检查 两 个 Random 实 例 是 否 产生 相同 的 随机 数 序列 ， 但 是 设计 
者 并 不 认为 客户 需要 或 者 期 望 这 样 的 功能 。 在 这 样 的 情况 下 ， 从 Object 继承 得 到 的 
equals 实 现 已 经 足够 了 。 


* 超 类 已 经 覆盖 了 equals， 从 超 类 继承 过 来 的 行为 对 于 子 类 也 是 合适 的 。 例 如 ， 大 多 数 的 
Set 实 现 都 从 AbstractSet 继 承 equals 实 现 ， List 实 现 从 AbstractList 继 承 equals 实 现 ， Map 
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实现 从 AbstractMap 继 承 equals 实 现 。 


。 类 是 私有 的 或 是 包 级 私有 的 ,可 以 确定 它 的 equals 方 法 永远 不 会 被 调用 。 在 这 种 情况 下 ， 
无 疑 是 应 该 覆盖 equals 方 法 的 ， 以 防 它 被 意外 调用 : 


@Override public boolean equals(Object o) { 
throw new AssertionError(); // Method is never called 


那么 ， 什 么 时 候 应 该 覆盖 Object.equals 呢 ? 如 果 类 具有 自己 特有 的 “逻辑 相等 ”概念 (不 
同 于 对 象 等 同 的 概念 )， 而 且 超 类 还 没有 覆盖 equals 以 实现 期 望 的 行为 ， 这 时 我 们 就 需要 覆盖 
equals 方 法 。 这 通常 属于 “ 值 类 (value class)” 的 情形 。 值 类 仅仅 是 一 个 表示 值 的 类 ， 例 如 
Integer 或 者 Date。 程 序 员 在 利用 equals 方 法 来 比较 值 对 象 的 引用 时 ， 希望 知道 它们 在 逻辑 上 是 
否 相 等 ， 而 不 是 想 了 解 它们 是 否 指向 同一 个 对 象 。 为 了 满足 程序 员 的 要 求 ， 不 仅 必需 覆盖 
equals 方 法 ,而 且 这 样 做 也 使 得 这 个 类 的 实例 可 以 被 用 做 映射 表 (map) 的 键 (key)， 或 者 集 
合 (set) 的 元 素 ， 使 映射 或 者 集合 表现 出 预期 的 行为 。 


有 一 种 “ 值 类 ”不 需要 覆盖 equals 方 法 ， 即 用 实例 受 控 ( 见 第 1 条 ) 确保 “每 个 值 至 多 只 
存在 一 个 对 象 ”的 类 。 枚 举 类 型 ( 见 第 30 条 ) 就 属于 这 种 类 。 对 于 这 样 的 类 而 言 ， 逻 辑 相 同 
与 对 象 等 同 是 一 回 事 ， 因 此 Object 的 equals 方 法 等 同 于 逻辑 意义 上 的 equals 方 法 。 


在 覆盖 equals 方 法 的 时 候 ， 你 必须 要 遵守 它 的 通用 约定 。 下 面 是 约定 的 内 容 ， 来 自 Object 
的 规范 [JavaSE6] : 


equals 方 法 实现 了 等 价 关 系 (equivalence relation) : 
。 自 反 性 (reflexive)。 对 于 任何 非 null 的 引用 值 x*，x.equals(x) 必 须 返 回 true。 


。 对 称 性 (symmetric)。 对 于 任何 非 null 的 引用 值 x* 和 y， 当 且 仅 当 y.equals(x) 返 回 true 时 ， 
x.equals(y) 必 须 返 回 true。. 


。 传 递 性 (transitive) 。 对 于 任何 非 null 的 引用 值 x、y 和 z， 如 果 x.equals(y) 返 回 true， 并 
且 y.equals(z) 也 返回 true， 那 么 x.equals(z) 也 必须 返回 true。 


。 一 致 性 (consistent)。 对 于 任何 非 null 的 引用 值 x< 和 y， 只 要 equals 的 比较 操作 在 对 象 中 
所 用 的 信息 没有 被 修改 ， 多 次 调用 x.equals(y) 就 会 一 致 地 返回 true， 或 者 一 致 地 返回 


false, 
。 对 于 任何 非 null 的 引用 值 x*，x.equals(null) 必 须 返 回 false。 
除非 你 对 数学 特别 感 兴趣 ， 否 则 这 些 规定 看 起 来 可 能 有 点 让 人 感到 恐 恨 ， 但 是 绝对 不 要 忽 
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视 这 些 规定 ! 如 果 你 违反 了 它们 ， 就 会 发 现 你 的 程序 将 会 表现 不 正常 ， 黄 至 崩溃 ， 而 且 很 难 
找到 失败 的 根源 。 用 John Donne 的 话说 ,没有 哪个 类 是 孤立 的 。 一 个 类 的 实例 通常 会 被 频繁 
地 传递 给 另 一 个 类 的 实例 。 有 许多 类 ， 包 括 所 有 的 集合 类 (collection class) 在 内 ， 都 依赖 于 
传递 给 它们 的 对 象 是 否 遵 守 了 equals 约 定 。 


现在 你 已 经 知道 了 违反 equals 约 定 有 多 么 可 怕 ， 现在 我 们 就 来 更 细致 地 讨论 这 些 约定 。 值 
得 欣慰 的 是 ， 这 些 约定 虽然 看 起 来 很 是 人， 实际 上 并 不 十 分 复杂 。 一 旦 理解 了 这 些 约定 ， 要 
遵守 它们 并 不 困难 。 现 在 我 们 按照 顺序 逐一 查看 以 下 5 个 要 求 : 


自 反 性 (reflexivity) 一 一 第 一 个 要 求 仅仅 说 明 对 象 必须 等 于 其 自身 。 很 难 想像 会 无 意识 
地 违反 这 一 条 。 假 如 违背 了 这 一 条 ， 然 后 把 该 类 的 实例 添加 到 集合 (collection) 中 ， 该 集合 
的 contains 方 法 将 果断 地 告诉 你 ， 该 集合 不 包含 你 刚刚 添加 的 实例 。 


WE (symmetry) 一 一 第 二 个 要 求 是 说 ， 任 何 两 个 对 象 对 于 “它们 是 否 相 等 ”的 问题 
都 必须 保持 一 致 。 与 第 一 个 要 求 不 同 ， 若 无 意 中 违 反 这 一 条 ， 这 种 情形 倒是 不 难 想像 。 例 如 ， 
考虑 下 面 的 类 ， 它 实现 了 一 个 区 分 大 小 写 的 字符 串 。 字 符 串 由 toString 保 存 ， 但 在 比较 操作 中 
被 忽略 。 


// Broken - violates symmetry! 
public final class CaseInsensitiveString { 
private final String s; 


public CaseInsensitiveString(String s) { 
if (s == null) 
throw new NullPointerException() ; 
this.s = s; 


} 


// Broken - violates symmetry! 
@Override public boolean equals(Object o) { 
if (o instanceof CaseInsensitiveString) 
return s.equalsIgnoreCase( 
((CaseInsensitiveString) 0).s); 
if (o instanceof String) // One-way interoperability! 
return s.equalsIgnoreCase((String) 0); 
return false; 


. // Remainder omitted 
在 这 个 类 中 ，equals 方 法 的 意图 非常 好 ， 它 企图 与 普通 的 字符 串 (String) 对 象 进行 互 操 
作 。 假 设 我 们 有 一 个 不 区 分 大 小 写 的 字符 串 和 一 个 普通 的 字符 串 : 


CaseInsensitiveString cis = new CaseInsensitiveString("Polish") ; 
String s = "polish"; 


正如 所 料 ，cis.equals(s) 返 回 true。 问 题 在 于 ， 虽 然 CaseInsensitiveString 类 中 的 equals 方 


对 于 所 有 对 象 郁 通 用 的 方法 31 


法 知道 普通 的 字符 串 (String) 对 象 ， 但 是 ，String 类 中 的 equals 方 法 却 并 不 知道 不 区 分 大 小 
写 的 字符 串 。 因 此 ，s.equals(cis) 返 回 false， 显 然 违 反 了 对 称 性 。 假 设 你 把 不 区 分 大 小 写 的 字 
符 串 对 象 放 到 一 个 集合 中 : 

List<CaseInsensitiveString> list = 


new ArrayList<CaseInsensitiveString>(); 
list.add(cis); 


此 时 list.contains(s) 会 返回 什么 结果 呢 ?” 没 人 知道 。 在 Sun 的 当前 实现 中 , 它 磁 巧 返回 false， 
但 这 只 是 这 个 特定 实现 得 出 的 结果 而 已 。 在 其 他 的 实现 中 ， 它 有 可 能 返回 true， 或 者 抛 出 一 个 
运行 时 (runtime) 异常 。 一 旦 违反 了 equals 约 定 。 当 其 他 对 象 面 对 你 的 对 象 时 ， 你 完全 不 知 
道 这 些 对 象 的 行为 会 怎么 样 。 


为 了 解决 这 个 问题 ， 只 需 把 企图 与 String 互 操作 的 这 段 代 码 从 equals 方 法 中 去 掉 就 可 以 了 。 
这 样 做 之 后 ， 就 可 以 重 构 该 方法 ， 使 它 变 成 一 条 单独 的 返回 语句 : 


@Override public boolean equals(Object o) { 
return o instanceof CaseInsensitiveString & 
((CaseInsensitiveString) 0).s.equalsIgnoreCase(s) ; 
} 


传递 性 (transitivity) 一 一 equals 约 定 的 第 三 个 要 求 是 ， 如 果 一 个 对 象 等 于 第 二 个 对 象 ， 
并 且 第 二 个 对 象 又 等 于 第 三 个 对 象 ， 则 第 一 个 对 象 一 定 等 于 第 三 个 对 象 。 同 样 地 ， 无 意识 地 
违反 这 条 规则 的 情形 也 不 难 想像 。 考 虑 子 类 的 情形 ， 它 将 一 个 新 的 值 组 件 .(yalue component) 
添加 到 了 超 类 中 。 换 句 话说 ， 子 类 增加 的 信息 会 影响 到 equals 的 比较 结果 。 我 们 首先 以 一 个 简 
单 的 不 可 变 的 二 维 整数 型 Point 类 作为 开始 : 


public class Point { 
private final int x; 
private final int y; 
public PointCint x, int y) { 
this.x = x; 
this.y = y; 


@Override public boolean equals(Object o) { 
if (!(o instanceof Point)) 
return false; 
Point p = (Point)o; 
return p.x == x && p.y == y; 


} 


. // Remainder omitted 


假设 你 想 要 扩展 这 个 类 ， 为 一 个 点 添加 颜色 信息 : 


public class ColorPoint extends Point i 
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private final Color color; 

public ColorPoint(int x, int y, Color color) { 
super(x, y); 
this.color = color; 


} 


// Remainder omitted 


equals 方 法 会 怎么 样 呢 ? 如 果 完 全 不 提供 equals 方 法 ， 而 是 直接 从 Point 继 承 过 来 ， 在 
equals 做 比较 的 时 候 颜 色 信 息 就 被 忽略 掉 了 。 虽 然 这 样 做 不 会 违反 equals 约 定 ， 但 是 很 明显 这 
是 无 法 接受 的 。 假 设 你 编写 了 一 个 equals 方 法 ， 只 有 当 它 的 参数 是 另 一 个 有 色 点 ， 并 且 具 有 同 
样 的 位 置 和 颜色 时 ， 它 才 会 返回 true: 

// Broken - violates symmetry 

@Override public boolean et oiai o) { 

if (!(o instanceof ColorPoint)) 


return false; 
return super.equals(o) && ((ColorPoint) o).color == color; 


这 个 方法 的 问题 在 于 ， 你 在 比较 普通 点 和 有 色 点 ， 以 及 相反 的 情形 时 ， 可 能 会 得 到 不 同 的 
结果 。 前 一 种 比较 忽略 了 颜色 信息 ， 而 后 一 种 比较 则 总 是 返回 false， 因 为 参数 的 类 型 不 正确 。 
为 了 直观 地 说 明 问 题 所 在 ， 我 们 创建 一 个 普通 点 和 一 个 有 色 点 : 


Point p = new Point(1, 2); 
ColorPoint cp = new ColorPoint(1, 2, Color.RED); 


然后 ，p.equals(cp) 返 回 true，cp.equals(p) 则 返回 false。 你 可 以 做 这 样 的 尝试 来 修正 这 个 
问题 ， 让 ColorPoint.equals 在 进行 “混合 比较 ”时 忽略 颜色 信息 : 


// Broken - violates transitivity! 
@Override public boolean equals(Object o) { 
if (!(o instanceof Point)) 
return false; 


// If o is a normal Point, do a color-blind comparison 
if (!(o instanceof ColorPoint)) 
return o.equals(this); 


// 0 is a ColorPoint; do a full comparison 
return super.equals(o) && ((ColorPoint)o).color == color; 


} 


这 种 方法 确实 提供 了 对 称 性 ， 但 是 却 牺 牲 了 传递 性 : 


ColorPoint pl = new ColorPoint(1, 2, Color.RED); 
Point p2 = new Point(1, 2); 
ColorPoint p3 = new ColorPoint(1, 2, Color.BLUE); 
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此 时 ，pl.equals(p2) 和 p2.equals(p3) 都 返回 true， 但 是 pl.equals(p3) 则 返回 false， 很 显然 
违反 了 传递 性 。 前 两 种 比较 不 考虑 颜色 信息 (“色盲 ”)， 而 第 三 种 比较 则 考虑 了 颜色 信息 。 


怎么 解决 呢 ? 事实 上 ， 这 是 面向 对 象 语言 中 关于 等 价 关 系 的 一 个 基本 问题 。 我 们 无 法 在 扩 
展 可 实例 化 的 类 的 同时 ， 既 增加 新 的 值 组 件 ， 同 时 又 保留 equals 约 定 ， 除 非 愿意 放弃 面向 对 象 
的 抽象 所 带 来 的 优势 。 


你 可 能 听 说 ， 在 equals 方 法 中 用 getClass 测 试 代替 instanceof 测 试 ， 可 以 扩展 可 实例 化 的 类 
和 增加 新 的 值 组 件 ， 同 时 保留 equals 约 定 : 


// Broken - violates Liskov substitution principle (page 40) 
@Override public boolean equals(Object o) { 
if (o == null || o.getClass() != getClass()) 
return false; 
Point p = (Point) o; 
return p.x == x && p.y == y; 


这 段 程序 只 有 当 对 象 具 有 相同 的 实现 时 ， 才 能 使 对 象 等 同 。 虽 然 这 样 也 不 算 太 糟糕 ， 但 是 
结果 却 是 无 法 接受 的 。 


假设 我 们 要 编写 一 个 方法 ， 以 检验 某 个 整 值 点 是 否 处 在 单位 圆 中 。 下 面 是 可 以 采用 的 其 中 
一 种 方法 : 


// Initialize UnitCircle to contain all Points on the unit circle 
private static final Set<Point> unitCircle; 
static { 
unitCircle = new HashSet<Point>(); 
unitCircle.add(new Point( 1, @)); 
unitCircle.add(new Point( @, 1)); 
unitCircle.add(new Point(-1, 0)); 
unitCircle.add(new Point( @, -1)); 
} 


public static boolean onUnitCircle(Point p) { 
return unitCircle.contains(p); 


虽然 这 可 能 不 是 实现 这 种 功能 的 最 快 方式 ， 不 过 它 的 效果 很 好 。 但 是 假设 你 通过 某 种 不 添 
加 值 组 件 的 方式 扩展 了 Point， 例 如 让 它 的 构造 器 记录 创建 了 多 少 个 实例 : 
public class CounterPoint extends Point { 
private static final AtomicInteger counter = 
new AtomicInteger(); 
public CounterPoint(int x, int y) { 
super(x, y); 
counter .incrementAndGet(); 


public int numberCreated() { return counter.get(); } 
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里 氏 替 换 原 则 (Liskov substitution principle) 认为 ， 一 个 类 型 的 任何 重要 属性 也 将 适用 
于 它 的 子 类 型 ， 因 此 为 该 类 型 编写 的 任何 方法 ,在 它 的 子 类 型 上 也 应 该 同样 运行 得 很 好 
[Liskov87]。 但 是 假设 我 们 将 CounterPoint 实 例 传 给 了 onUnitCircle 方 法 。 如 果 Point 类 使 用 了 
基于 getClass 的 equals 方 法 ， 无 论 CounterPoint 实 例 的 x 和 y 值 是 什么 ，onUnitCircle 方 法 都 会 返 
回 false。 之 所 以 如 此 ， 是 因为 像 onUnitCircle 方 法 所 用 的 HashSet 这 样 的 集合 ， 利 用 equals 方 
法 检验 包含 条 件 ， 没 有 任何 CounterPoint 实 例 与 任何 Point 对 应 。 但 是 ， 如 果 在 Point 上 使 用 适 
当 的 基于 instanceof 的 equals 方 法 ， 当 遇 到 CounterPoint 时 ， 相 同 的 onUnitCircle 方 法 就 会 工作 
得 很 好 。 


虽然 没有 一 种 令 人 满意 的 办 法 可 以 既 扩 展 不 可 实例 化 的 类 ， 又 增加 值 组 件 ， 但 还 是 有 一 种 
不 错 的 权宜 之 计 (workaround) 。 根 据 第 16 条 的 建议 : 复合 优先 于 继承 。 我 们 不 再 让 ColorPoint 
扩展 Point， 而 是 在 ColorPoint 中 加 入 一 个 私有 的 Point 域 ， 以 及 一 个 公有 的 视图 (view) 方法 
( 见 第 5 条 ) ， 此 方法 返回 一 个 与 该 有 色 点 处 在 相同 位 置 的 普通 Point 对 象 ; 
// Adds a value component without violating the equals contract 
public class ColorPoint { 
private final Point point; 
private final Color color; 
public ColorPoint(int x, int y, Color color) { 
if (color == null) 
throw new Nul1PointerException() ; 


point = new Point(x, y); 
this.color =, color; 


[ur 
* Returns the point-view of this color point. 


*/ 
public Point asPoint() { 
return point; 


@Override public boolean equals(Object o) { 
if (!(o instanceof ColorPoint)) 
return false; 
ColorPoint cp = (ColorPoint) o; 
return cp.point.equals(point) && cp.color.equals(color); 


} 


. // Remainder omitted 


在 Java 平 台 类 库 中 ， 有 一 些 类 扩展 了 可 实例 化 的 类 ， 并 添加 了 新 的 值 组 件 。 例 如 ， 
java.sql,Timestamp 对 java.util.Date 进 行 了 扩展 ， 并 增加 了 nanoseconds 域 。Timestamp 的 equals 
实现 确实 违反 了 对 称 性 ， 如 果 Timestamp 和 Date 对 象 被 用 于 同一 个 集合 中 ， 或 者 以 其 他 方式 被 
混合 在 一 起 ， 则 会 引起 不 正确 的 行为 。Timestamp 类 有 一 个 免责 声明 ， 告 诫 程序 员 不 要 混合 使 
用 Date 和 Timestamp 对 象 。 只 要 你 不 把 它们 混合 在 一 起 ， 就 不 会 有 麻烦 ， 除 此 之 外 没有 其 他 的 
措施 可 以 防止 你 这 么 做 , 而 且 结 果 导 致 的 错误 将 很 难 调试 。Timestamp 类 的 这 种 行为 是 个 错误 ， 
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不 值得 仿效 。 


注意 ， 你 可 以 在 一 个 抽象 (abstract) 类 的 子 类 中 增加 新 的 值 组 件 ， 而 不 会 违反 equals 约 
定 。 对 于 根据 第 20 条 的 建议 “用 类 层次 (class hierarchies) 代替 标签 类 (tagged class)” 而 得 
到 的 那 种 类 层次 结构 来 说 ， 这 一 点 非常 重要 。 例 如 ， 你 可 能 有 一 个 抽象 的 Shape 类 ， 它 没有 任 
何 值 组 件 ，Circle 子 类 添加 了 一 个 radius 域 ， Rectangle 子 类 添加 了 length 和 width 域 。 只 要 不 可 
能 直接 创建 超 类 的 实例 ， 前 面 所 述 的 种 种 问题 就 都 不 会 发 生 。 


一 致 性 (consistency) 一 一 equals 约 定 的 第 四 个 要 求 是 ， 如 果 两 个 对 象 相等 ， 它们 就 必 
须 始终 保持 相等 ， 除 非 它们 中 有 一 个 对 象 (或 者 两 个 都 ) 被 修改 了 。 换 句 话说 ， 可 变 对 象 在 
不 同 的 时 候 可 以 与 不 同 的 对 象 相 等 ， 而 不 可 变 对 象 则 不 会 这 样 。 当 你 在 写 一 个 类 的 时 候 ， 应 
该 仔细 考虑 它 是 否 应 该 是 不 可 变 的 ( 见 第 15 条 ) 。 如 果 认 为 它 应 该 是 不 可 变 的 ， 就 必须 保证 
equals 方 法 满足 这 样 的 限制 条 件 ， 相 等 的 对 象 永远 相等 ， 不 相等 的 对 象 永远 不 相等 。 


无 论 类 是 否 是 不 可 变 的 ,都 不 要 使 equals 方 法 依赖 于 不 可 靠 的 资源 。 如 果 违 反 了 这 条 禁令 ， 
要 想 满足 一 致 性 的 要 求 就 十 分 困难 了 。 例 如 ， java.net.URL 的 equals 方 法 依赖 于 对 URL 中 主机 
IP 地 址 的 比较 。 将 一 个 主机 名 转变 成 IP 地 址 可 能 需要 访问 网 络 ， 随 着 时 间 的 推移 ， 不 确保 会 产 
生 相 同 的 结果 。 这 样 会 导致 URL 的 equials 方 法 违反 equals 约 定 ， 在 实践 中 有 可 能 引发 一 些 问题 。 
(遗憾 的 是 ， 因 为 兼容 性 的 要 求 ， 这 一 行为 无 法 被 改变 。) 除了 极 少数 的 例外 情况 ， equals 方 法 
都 应 该 对 驻 留 在 内 存 中 的 对 象 执行 确定 性 的 计算 。 


非 空 性 (Non-nullity) 一 一 最 后 一 个 要 求 没有 名 称 ， 我 姑且 称 它 为 “ 非 空 性 (Non- 
nullity)"， 意 思 是 指 所 有 的 对 象 都 必须 不 等 于 null。 尽管 很 难 想像 什么 情况 下 o.equals (null) 
调用 会 意外 地 返回 true， 但 是 意外 抛 出 NullPointerException 异 常 的 情形 却 不 难 想像 。 通 用 约 
定 不 允许 抛 出 NullPointerException 异 常 。 许多 类 的 equals 方 法 都 通过 一 个 显 式 的 null 测 试 来 
防止 这 种 情况 : 

@Override public boolean equals(Object o) { 


if (o == null) 
return false; 


} 


这 项 测试 是 不 必要 的 。 为 了 测试 其 参数 的 等 同性 ， equals 方 法 必须 先 把 参数 转换 成 适当 的 
类 型 ， 以 便 可 以 调用 它 的 访问 方法 (accessor) ， 或 者 访问 它 的 域 。 在 进行 转换 之 前 ，equals 方 
法 必须 使 用 instanceof 操 作 符 ， 检 查 其 参数 是 否 为 正确 的 类 型 ， 


@Override public boolean equals(Object o) { 
if (!(o instanceof MyType)) 
return false; 
MyType mt = (MyType) 0; 


36 RIF 
} 


如 果 漏 掉 了 这 一 步 的 类 型 检查 ， 并 且 传 递 给 equals 方 法 的 参数 又 是 错误 的 类 型 ， 那 么 
equals 方 法 将 会 抛 出 ClassCastException 异 常 ， 这 就 违反 了 equals 的 约定 。 但 是 ， 如 果 
instanceof 的 第 一 个 操作 数 为 null， 那 么 ， 不 管 第 二 个 操作 数 是 哪 种 类 型 ，instanceof 操 作 符 都 
指定 应 该 返回 false[JLS，15.20.2]。 因 此 ， 如 果 把 null 传 给 equals 方 法 ， 类 型 检查 就 会 返回 
false， 所 以 不 需要 单独 的 null 检 查 。 


结合 所 有 这 些 要 求 ， 得 出 了 以 下 实现 高 质量 equals 方 法 的 诀窍 : 


1. 使 用 == 操 作 符 检查 “参数 是 否 为 这 个 对 象 的 引用 "。 如 果 是 ， 则 返回 true。 这 只 不 过 是 
一 种 性 能 优化 ， 如 果 比 较 操 作 有 可 能 很 昂贵 ， 就 值得 这 么 做 。 


2. 使 用 instanceof 操 作 符 检查 “参数 是 否 为 正确 的 类 型 " 。 如 果 不 是 ， 则 返回 false。 一 般 
说 来 ， 所 谓 “ 正 确 的 类 型 ”是 指 equals 方 法 所 在 的 那个 类 。 有 些 情 况 下 ， 是 指 该 类 所 实现 的 
某 个 接口 。 如 果 类 实现 的 接口 改进 了 equals 约 定 ， 人 允许 在 实现 了 该 接口 的 类 之 间 进 行 比较 ， 
那么 就 使 用 接口 。 集 合 接口 (collection interface) 如 Set、List、Map 和 Map.Entry 具 有 这 样 
的 特性 。 


3. 把 参数 转换 成 正确 的 类 型 。 因 为 转换 之 前 进行 过 instanceof 测 试 ， 所 以 确保 会 成 功 。 


4. 对 于 该 类 中 的 每 个 “关键 (significant)” 域 ， 检 查 参数 中 的 域 是 否 与 该 对 象 中 对 应 的 
域 相 匹 配 。 如 果 这 些 测试 全 部 成 功 ， 则 返回 true， 否则 返回 false。 如 果 第 2 步 中 的 类 型 是 个 接 
口 ， 就 必须 通过 接口 方法 访问 参数 中 的 域 ， 如 果 该 类 型 是 个 类 ， 也 许 就 能 够 直接 访问 参数 中 
的 域 ， 这 要 取决 于 它们 的 可 访问 性 。 


对 于 既 不 是 float 也 不 是 double 类 型 的 基本 类 型 域 ， 可 以 使 用 == 操 作 符 进行 比较 ， 对 于 对 
象 引 用 域 ， 可 以 递归 地 调用 equals 方 法 ， 对 于 float 域 ， 可 以 使 用 Float.compare 方 法 ， 对 于 
double 域 ， 则 使 用 Double.compare。 对 float 和 double 域 进行 特殊 的 处 理 是 有 必要 的 ， 因 为 存在 
着 Float.NaN、-0.0f 以 及 类 似 的 double 常 量 ;， 详细 信 息 请 参考 Float.equals 的 文档 。 对 于 数组 域 ， 
则 要 把 以 上 这 些 指导 原则 应 用 到 每 个 元 素 上 。 如 果 数 组 域 中 的 每 个 元 素 都 很 重要 ， 就 可 以 使 
用 发 行 版 本 1.5 中 新 增 的 其 中 一 个 Arrays.equals 方 法 。 


有 些 对 象 引 用 域 包含 null 可 能 是 合法 的 ， 所 以 ， 为 了 避免 可 能 导致 NullPointerException 异 
常 ， 则 使 用 下 面 的 习惯 用 法 来 比较 这 样 的 域 : 


(field == null ? o.field == null : field.equals(o.field)) 


如 果 field 和 o.field 通 常 是 相同 的 对 象 引 用 ， 那 么 下 面 的 做 法 就 会 更 快 一 些 : 
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(field == o.field || (field != null && field.equals(o.field))) 


对 于 有 些 类 ， 比 如 前 面 提 到 的 CaseInsensitiveString 类 ， 域 的 比较 要 比 简单 的 等 同性 测试 
复杂 得 多 。 如 果 是 这 种 情况 ， 可 能 会 希望 保存 该 域 的 一 个 “范式 (canonical form)”, ix 
equals 方 法 就 可 以 根据 这 些 范式 进行 低 开 销 的 精确 比较 ， 而 不 是 高 开销 的 非 精 确 比 较 。 这 种 方 
法 对 于 不 可 变 类 ( 见 第 15 条 ) 是 最 为 合适 的 ;如 果 对 象 可 能 发 生变 化 ， 就 必须 使 其 范式 保持 
最 新 。 


域 的 比较 顺序 可 能 会 影响 到 equals 方 法 的 性 能 。 为 了 获得 最 佳 的 性 能 ， 应 该 最 先 比较 最 有 
可 能 不 一 致 的 域 ， 或 者 是 开销 最 低 的 域 ， 最 理想 的 情况 是 两 个 条 件 同时 满足 的 域 。 你 不 应 该 
去 比较 那些 不 属于 对 象 逻 辑 状态 的 域 ， 例 如 用 于 同步 操作 的 Lock 域 。 也 不 需要 比较 元 余 域 
(redundant field)， 因 为 这 些 元 余 域 可 以 由 “关键 域 ” 计 算 获 得 ， 但 是 这 样 做 有 可 能 提高 
equals 方 法 的 性 能 。 如 果 宛 余 域 代表 了 整个 对 象 的 综合 描述 ， 比 较 这 个 域 可 以 节省 当 比较 失败 
时 去 比较 实际 数据 所 需要 的 开销 。 例 如 ， 假 设 有 一 个 Polygon 类 ， 并 缓存 了 该 区 域 。 如 果 两 个 
多 边 形 有 着 不 同 的 区 域 ， 就 没有 必要 去 比较 它们 的 边 和 至 高 点 。 


5. 当 你 编写 完成 了 equals 方 法 之 后 ， 应 该 问 自己 三 个 问题 : 它 是 否 是 对 称 的 、 传 递 的 、 
一 致 的 ? 并 且 不 要 只 是 自问 ， 还 要 编写 单元 测试 来 检验 这 些 特性 ! 如 果 答 案 是 否定 的 ， 就 要 
找 出 原因 ， 再 相应 地 修改 equals 方 法 的 代码 。 当 然 ，equals 方 法 也 必须 满足 其 他 两 个 特性 ( 自 
反 性 和 非 空 性 ) ， 但 是 这 两 种 特性 通常 会 自动 满足 。 


根据 上 面 的 诀窍 构建 的 equals 方 法 的 具体 例子 ， 请 参看 第 9 条 的 PhoneNumber. equals, F 
面 是 最 后 的 一 些 告 诫 ， 

。 覆 盖 equals 时 总 要 覆盖 hashCode ( 见 第 9 条 )。 

。 不 要 企图 让 equals 方 法 过 于 智能 。 如 果 只 是 简单 地 测试 域 中 的 值 是 否 相 等 ， 则 不 难 做 到 

遵守 equals 约 定 。 如 果 想 过 度 地 去 寻求 各 种 等 价 关 系 ， 则 很 容易 陷 人 麻烦 之 中 。 把 任何 

一 种 别名 形式 考虑 到 等 价 的 范围 内 ， 往 往 不 会 是 个 好 主意 。 例 如 ，File 类 不 应 该 试图 把 


指向 同一 个 文件 的 符号 链接 (symbolic link) 当 作 相等 的 对 象 来 看 待 。 所 幸 File 类 没有 
这 样 做 。 


。 不 要 将 equals 声 明 中 的 Object 对 象 替换 为 其 他 的 类 型 。 程 序 员 编写 出 下 面 这 样 的 equals 
方法 并 不 鲜 见 ， 这 会 使 程序 员 花 上 数 个 小 时 都 搞 不 清 为 什么 它 不 能 正常 工作 : 


public boolean equals(MyClass o) { 
} 


问题 在 于 ， 这 个 方法 并 没有 覆盖 Object.equals， 因 为 它 的 参数 应 该 是 Object 类 型 ， 相 反 ， 
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ER (overload) 了 Object.equals ( 见 第 41 条 )。 在 原 有 equals 方 法 的 基础 上 ， 再 提供 一 个 
“ 强 类 型 (strongly typed)” 的 equals 方 法 ， 只 要 这 两 个 方法 返回 同样 的 结果 (没有 强制 的 理 
.由 必须 这 样 做 ) ， 那 么 这 就 是 可 以 接受 的 。 在 某 些 特定 的 情况 下 ， 它 也 许 能 够 稍微 改善 性 能 ， 
但 是 与 增加 的 复杂 性 相 比 ， 这 种 做 法 是 不 值得 的 ( 见 第 55 条 )。 





@Override 注 解 的 用 法 一 致 ， 就 如 本 条 目 中 所 示 ， 可 以 防止 犯 这 种 错误 ( 见 第 36 条 )。 这 
个 equals 方 法 不 能 编译 ， 错 误 消 息 会 告诉 你 到 底 哪 里 出 了 问题 : 


@Override public boolean equals(MyClass o) { 
} 
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第 9 条 : 覆盖 equals 时 总 要 覆盖 has ey pa — ia vagi Erap Ifs 






一 个 很 常见 的 错误 根源 在 于 没有 覆盖 hashCode 方 法 。 在 每 个 覆盖 了 equals 方 法 的 类 中 ， 
也 必须 履 盖 hashCode 方 法 。 如 果 不 这 样 做 的 话 ， 就 会 违反 Object.hashiCode 的 通用 约定 ， 从 而 
导致 该 类 无 法 结合 所 有 基于 散 列 的 集合 一 起 正常 运作 ， 这 样 的 集合 包括 HashMap、HashSet 和 
Hashtable, j 


下 面 是 约定 的 内 容 ， 摘 自 Object 规 范 [JavaSE6]: 


© 在 应 用 程序 的 执行 期 间 ， 只 要 对 象 的 equals 方 法 的 比较 操作 所 用 到 的 信息 没有 被 修改 ， 
那么 对 这 同一 个 对 象 调 用 多 次 ，hashCode 方 法 都 必须 始终 如 一 地 返回 同一 个 整数 。 在 同 
一 个 应 用 程序 的 多 次 执行 过 程 中 ， 每 次 执行 所 返回 的 整数 可 以 不 一 致 。 


© 如果 两 个 对 象 根 据 equals(Object) 方 法 比较 是 相等 的 ， 那 么 调用 这 两 个 对 象 中 任意 一 个 对 
象 的 hashCode 方 法 都 必须 产生 同样 的 整数 结果 。 


© 如果 两 个 对 象 根据 equals(Object) 方 法 比较 是 不 相等 的 ， 那 么 调用 这 两 个 对 象 中 任意 一 个 
对 象 的 hashCode 方 法 ， 则 不 一 定 要 产生 不 同 的 整数 结果 。 但 是 程序 员 应 该 知道 ， 给 不 相 
等 的 对 象 产生 截然 不 同 的 整数 结果 ， 有 可 能 提高 散 列 表 (hash table) 的 性 能 。 


因 没 有 履 盖 hashCode 而 违反 的 关键 约定 是 第 二 条 : 相等 的 对 象 必 须 具 有 相等 的 散 列 码 
(hash code)。 根 据 类 的 equals 方 法 ， 两 个 截然 不 同 的 实例 在 逻辑 上 有 可 能 是 相等 的 ， 但 是 ， 
根据 Object 类 的 hashCode 方 法 ， 它 们 仅仅 是 两 个 没有 任何 共同 之 处 的 对 象 。 因 此 ， 对 象 的 
hashCode 方 法 返回 两 个 看 起 来 是 随机 的 整数 ， 而 不 是 根据 第 二 个 约定 所 要 求 的 那样 ， 返 回 两 
个 相等 的 整数 。 


例如 ， 考 虑 下 面 这 个 极为 简单 的 PhoneNumber 类 ， 它 的 equals 方 法 是 根据 第 8 条 中 给 出 的 
“诀窍 ”构造 出 来 的 : 


public final class PhoneNumber { 
private final short areaCode; 
private final short prefix; 
private final short lineNumber; 


public PhoneNumber(int areaCode, int prefix, 
int lineNumber) { 

rangeCheck(areaCode, 999, "area code"); 
rangeCheck (prefix, 999, "prefix"); 
rangeCheck(lineNumber, 9999, "line number"); 
‘this.areaCode = (short) areaCode; 
this.prefix = (short) prefix; 
this.]ineNumber = (short) lineNumber; 
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private static void rangeCheck(int arg, int max, 
String name) { 
if (arg <0 || arg > max) 
throw new IllegalArgumentException(name +": " + arg); 
} 
@Override public boolean equals(Object o) { 
if (o == this) 
return true; 
if (!(o instanceof PhoneNumber)) 
return false; 
PhoneNumber pn = (PhoneNumber)o; 
return pn.lineNumber == lineNumber 
&& pn.prefix == prefix 
&& pn.areaCode == areaCode; 
} 
// Broken - no hashCode method! 


... // Remainder omitted 


假设 你 企图 将 这 个 类 与 HashMap 一 起 使 用 : 


Map<PhoneNumber, String> m 
= new HashMap<PhoneNumber, String>(); 

m.put(new PhoneNumber(707, 867, 5309), “Jenny"); 

这 时 候 ， 你 可 能 期 望 m.get(new PhoneNumber(408, 867, 5309)) 会 返回 “Jenny”， 但 它 实 
际 上 返回 的 是 null。 注意， 这 里 涉及 两 个 PhoneNumber 实 例 : 第 一 个 被 用 于 插入 到 HashMap 中 ， 
第 二 个 实例 与 第 一 个 相等 ， 被 用 于 (试图 用 于 ) 获取 。 由 于 PhoneNumber 类 没有 覆盖 
hashCode 方 法 ， 从 而 导致 两 个 相等 的 实例 具有 不 相等 的 散 列 码 ， 违 反 了 hashCode 的 约定 。 因 
此 ，put 方 法 把 电话 号 码 对 象 存放 在 一 个 散 列 桶 (hash bucket) 中 ，get 方 法 却 在 另 一 个 散 列 桶 
中 查找 这 个 电话 号 码 。 即 使 这 两 个 实例 正好 被 放 到 同一 个 散 列 桶 中 ，get 方 法 也 必定 会 返回 
null ， 因 为 HashMap 有 一 项 优化 ， 可 以 将 与 每 个 项 相关 联 的 散 列 码 缓存 起 来 ， 如 果 散 列 码 不 葡 
配 ， 也 不 必 检 验 对 象 的 等 同性 。 


修正 这 个 问题 非常 简单 ， 只 需 为 PhoneNumber 类 提供 一 个 适当 的 hashCode 方 法 即 可 。 那 
么 ，hashCode 方 法 应 该 是 什么 样 的 呢 ? 编写 一 个 合法 但 并 不 好 用 的 hashCode 方 法 没有 任何 价 
值 。 例 如 ， 下 面 这 个 方法 总 是 合法 ， 但 是 永远 都 不 应 该 被 正式 使 用 : 


// The worst possible legal hash function - never use! 
@Override public int hashCode() { return 42; } 


上 面 这 个 hashCode 方 法 是 合法 的 ， 因 为 它 确保 了 相等 的 对 象 总 是 具有 同样 的 散 列 码 。 但 
它 也 极为 恶劣 ， 因 为 它 使 得 每 个 对 象 都 具有 同样 的 散 列 码 。 因 此 ， 每 个 对 象 都 被 映射 到 同一 
个 散 列 桶 中 ， 使 散 列 表 退 化 为 链表 (linked list) 。 它 使 得 本 该 线性 时 间 运 行 的 程序 变 成 了 以 平 
方 级 时 间 在 运行 。 对 于 规模 很 大 的 散 列表 而 言 ， 这 会 关系 到 散 列表 能 否 正常 工作 。 
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一 个 好 的 散 列 函 数 通 常 倾向 于 “为 不 相等 的 对 象 产 生 不 相等 的 散 列 码 ”。 这 正 是 hashCode 
约定 中 第 三 条 的 含义 。 理 想 情况 下 ， 散 列国 数 应 该 把 集合 中 不 相等 的 实例 均匀 地 分 布 到 所 有 
可 能 的 散 列 值 上 。 要 想 完全 达到 这 种 理想 的 情形 是 非常 困难 的 。 幸 运 的 是 ， 相 对 接近 这 种 理 
想 情 形 则 并 不 太 困难 。 下 面 给 出 一 种 简单 的 解决 办 法 : 


1. 把 某 个 非 零 的 常数 值 ， 比 如 说 17， 保 存在 一 个 名 为 result 的 int 类 型 的 变量 中 。 
2. 对 于 对 象 中 每 个 关键 域 f( 指 equals 方 法 中 涉及 的 每 个 域 )， 完 成 以 下 步骤 : 
a. 为 该 域 计算 int 类 型 的 散 列 码 c: 
i. 如 果 该 域 是 boolean 类 型 ， 则 计算 (f ? 1 : 0)。 
ii， 如 果 该 域 是 byte、char、short 或 者 int 类 型 Mit nf. 
iii. 如 果 该 域 是 long 类 型 ， 则 计算 (int)(f ^(f >>> 32))。 
iv， 如 果 该 域 是 float 类 型 ， 则 计算 Float.floatToIntBits(f)。 


v， 如 果 该 域 是 double 类 型 ， 则 计算 Double.doubleToLongBits(f)， 然 后 按照 步骤 
2.a.iii， 为 得 到 的 long 类 型 值 计 算 散 列 值 。 


vi. 如 果 该 域 是 一 个 对 象 引 用 ， 并 且 该 类 的 equals 方 法 通过 递归 地 调用 equals 的 方式 来 
比较 这 个 域 ， 则 同样 为 这 个 域 递 归 地 调用 hashCode。 如 果 需 要 更 复杂 的 比较 ， 则 
为 这 个 域 计 算 一 个 “范式 (canonical representation)”， 然 后 针对 这 个 范式 调用 
hashCode。 如 果 这 个 域 的 值 为 null， 则 返回 0 (或 者 其 他 某 个 常数 ， 但 通常 是 0) 。 


vii. 如 果 该 域 是 一 个 数组 ， 则 要 把 每 一 个 元 素 当 做 单独 的 域 来 处 理 。 也 就 是 说 ， 递 归 
地 应 用 上 述 规则 ， 对 每 个 重要 的 元 素 计算 一 个 散 列 码 ， 然 后 根据 步骤 2.b 中 的 做 法 
把 这 些 散 列 值 组 合 起 来 。 如 果 数 组 域 中 的 每 个 元 素 都 很 重要 ， 可 以 利用 发 行 版 本 
1.5 中 增加 的 其 中 一 个 Arrays.hashCode 方 法 。 


b. 按照 下 面 的 公式 ， 把 步骤 2.a 中 计算 得 到 的 散 列 码 c 合 并 到 result 中 : 
result = 31 + result + C; 


3. 返回 result。 


. 写 完了 hashCode 方 法 之 后 ， 问 问 自己 “相等 的 实例 是 否 都 具有 相等 的 散 列 码 ”。 要 编 
Ernie blak aerial 如 果 相 等 的 实例 有 着 不 相等 的 散 列 码 ， 则 要 找 出 原因 ， 并 修正 
错误 。 
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在 散 列 码 的 计算 过 程 中 ， 可 以 把 完 余 域 (redundant field) 排除 在 外 。 换 和 铝 话 说， 如果 
一 个 域 的 值 可 以 根据 参与 计算 的 其 他 域 值 计 算出 来 ， 则 可 以 把 这 样 的 域 排除 在 外 。 必 须 排除 
equals 比 较 计 算 中 没有 用 到 的 任何 域 ， 否 则 很 有 可 能 违反 hashCode 约 定 的 第 二 条 。 


上 述 步骤 1 中 用 到 了 一 个 非 零 的 初始 值 ， 因 此 步骤 2.a 中 计算 的 散 列 值 为 0 的 那些 初始 域 ， 
` 会 影响 到 散 列 值 。 如 果 步 又 1 中 的 初始 值 为 0， 则 整个 散 列 值 将 不 受 这 些 初 始 域 的 影响 ， 因 为 
这 些 初 始 域 会 增加 冲突 的 可 能 性 。 值 17 则 是 任 选 的 。 


步骤 2.b 中 的 乘法 部 分 使 得 散 列 值 依赖 于 域 的 顺序 ， 如 果 一 个 类 包含 多 个 相似 的 域 ， 这 样 
的 乘法 运算 就 会 产生 一 个 更 好 的 散 列 函 数 。 例 如 ， 如 果 String 散 列 函 数 省 略 了 这 个 乘法 部 分 ， 
那么 只 是 字母 顺序 不 同 的 所 有 字符 串 都 会 有 相同 的 散 列 码 。 之 所 以 选择 31， 是 因为 它 是 一 个 
奇 素数 。 如 果 乘 数 是 偶数 ， 并 且 乘 法 溢出 的 话 ， 信息 就 会 丢失 ， 因 为 与 2 相 乘 等 价 于 移 位 运算 。 
使 用 素数 的 好 处 并 不 很 明显 ， 但 是 习惯 上 都 使 用 素数 来 计算 散 列 结果 。31 有 个 很 好 的 特性 ， 
即 用 移 位 和 减法 来 代替 乘法 ， 可 以 得 到 更 好 的 性 能 : 31 * i == (i << 5)-i, 现代 的 VM 可 以 自 
动 完成 这 种 优化 。 


现在 我 们 要 把 上 述 的 解决 办 法 用 到 PhoneNumber 类 中 。 它 有 三 个 关键 域 ， 都 是 short 类 型 ， 


@Override public int hashCode() { 
int result = 17; 
result = 31 + result + areaCode; 
result = 31 * result + prefix; 
result = 31 + result + lineNumber; 
return result; 


} 


因为 这 个 方法 返回 的 结果 是 一 个 简单 的 、 确 定 的 计算 结果 ， 它 的 输入 只 是 PhoneNumber 
实例 中 的 三 个 关键 域 ， 因 此 相等 的 PhoneNumber 显 然 都 会 有 相等 的 散 列 码 。 实 际 上 ， 对 于 
PhoneNumber 的 hashCode 实 现 而 言 ， 上 面 这 个 方法 是 非常 合理 的 ， 相 当 于 Java 平 台 类 库 中 的 
实现 。 它 的 做 法 非常 简单 ， 也 相当 快捷 ， 恰 当地 把 不 相等 的 电话 号 码 分 散 到 不 同 的 散 列 桶 中 。 


如 果 一 个 类 是 不 可 变 的， 并 且 计 算 散 列 码 的 开销 也 比较 大 ， 就 应 该 考虑 把 散 列 码 缓存 在 对 
象 内 部 ， 而 不 是 每 次 请 求 的 时 候 都 重新 计算 散 列 码 。 如 果 你 觉得 这 种 类 型 的 大 多 数 对 象 会 被 
用 做 散 列 键 (hash keys), ， 就 应 该 在 创建 实例 的 时 候 计 算 散 列 码 。 否 则 ， 可 以 选择 “延迟 初始 
化 (lazily initialize)” ” 散 列 码 ， 一 直到 hashCode 被 第 一 次 调用 的 时 候 才 初始 化 〈 见 第 71 条 ) 。 
现在 尚 不 清楚 我 们 的 PhoneNumber 类 是 否 值得 这 样 处 理 ， 但 可 以 通过 它 来 说 明 这 种 方法 该 如 
何 实现 : 


// Lazily initialized, cached hashCode 
private volatile int hashCode; // (See Item 71) 


@Override public int hashCode() { 
int result = hashCode; 
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if (result == 0) { 
result = 17; 
result = 31 * result + areaCode; 
result = 31 * result + prefix; 
result = 31 + result + lineNumber; 
hashCode = result; 


return result; 


} 


虽然 本 条 目 中 前 面 给 出 的 hashCode 实 现 方法 能 够 获得 相当 好 的 散 列 函 数 ， 但 是 它 并 不 能 
产生 最 新 的 散 列 函 数 ， 截 止 发 行 版 本 1.6，Java 平 台 类 库 也 没有 提供 这 样 的 散 列 函数 。 编 写 这 
种 散 列 函 数 是 个 研究 课题 ， 最 好 留 给 数学 家 和 理论 方面 的 计算 机 科学 家 来 完成 。 也 许 Java 平 台 
的 下 一 个 发 行 版 本 将 会 为 它 的 类 提供 这 种 最 佳 的 散 列 函数 ， 并 提供 一 些 实用 方法 来 帮助 普通 
的 程序 员 构 造 出 这 样 的 散 列 函 数 。 与 此 同时 ， 本 条 目 中 介绍 的 方法 对 于 绝 大 多 数 应 用 程序 而 
言 已 经 足够 了 。 


不 要 试图 从 散 列 码 计算 中 排除 掉 一 个 对 象 的 关键 部 分 来 提高 性 能 。 虽 然 这 样 得 到 的 散 列 函 
数 运行 起 来 可 能 更 快 ， 但 是 它 的 效果 不 见得 会 好 ， 可 能 会 导致 散 列表 慢 到 根本 无 法 使 用 。 特 
别 是 在 实践 中 ， 散 列 函 数 可 能 面临 大 量 的 实例 ， 在 你 选择 忽略 的 区 域 之 中 ， 这 些 实例 仍然 区 
别 非常 大 。 如 果 是 这 样 ， 散 列 函 数 就 会 把 所 有 这 些 实例 映射 到 极 少数 的 散 列 码 上 ， 基 于 散 列 
的 集合 将 会 显示 出 平方 级 的 性 能 指标 。 这 不 仅仅 是 个 理论 问题 。 在 Java 1.2 发 行 版 本 之 前 实现 
的 String 散 列 函 数 至 多 只 检查 16 个 字符 ， 从 第 一 个 字符 开始 ， 在 整个 字符 串 中 均匀 选取 。 对 于 
像 URL 这 种 层次 状 名 字 的 大 型 集合 ， 该 散 列 函数 正好 表现 出 了 这 里 所 提 到 的 病态 行为 。 


Java 平 台 类 库 中 的 许多 类 ， 比 如 String、Integer 和 Date， 都 可 以 把 它们 的 hashCode 方 法 返 
回 的 确切 值 规定 为 该 实例 值 的 一 个 函数 。 一 般 来 说 ， 这 并 不 是 个 好 主意 ， 因 为 这 样 做 严格 地 
限制 了 在 将 来 的 版 本 中 改进 散 列 函数 的 能 力 。 如 果 没 有 规定 散 列 函数 的 细节 ， 那 么 当 你 发 现 
了 它 的 内 部 缺陷 时 ， 就 可 以 在 后 面 的 发 行 版 本 中 修正 它 ， 确 信 没 有 任何 客户 端 会 依赖 于 散 列 
函数 返回 的 确切 值 。 





虽然 jave.lang.Object 提 供 了 toString 方 法 的 一 个 实现 ， 但 它 返 回 的 字符 串通 常 并 不 是 类 的 
用 户 所 期 望 看 到 的 。 它 包含 类 的 名 称 ， 以 及 一 个 “@” 符 号 ， 接着 是 散 列 码 的 无 符号 十 六 进 
制 表示 法 ， 例 如 “PhoneNumber@163b91"。toString 的 通用 约定 指出 ， 被 返回 的 字符 串 应 该 
是 一 个 “简洁 的 ， 但 信息 丰富 ， 并 且 易 于 阅读 的 表达 形式 ” [JavaSE6]。 尽 管 有 人 认为 
“PhoneNumber@163b91” 算 得 上 是 简洁 和 易于 阅读 了 ， 但 是 与 “(707)867-5309” 比 较 起 来 ， 
它 还 算 不 上 是 信息 丰富 的 。toString 的 约定 进一步 指出 ， “建议 所 有 的 子 类 都 覆盖 这 个 方法 。” 
这 是 一 个 很 好 的 建议 ， 真 的 | 


虽然 遵守 toString 的 约定 并 不 像 遵守 equals 和 hashCode 的 约定 ( 见 第 8 条 和 第 9 条 ) 那么 重要 ， 
但 是 ， 提 供 好 的 toString 实 现 可 以 使 类 用 起 来 更 加 舒适 。 当 对 象 被 传递 给 printin、printf 字符 串 
联 操 作 符 (+) 以 及 assert 或 者 被 调试 器 打印 出 来 时 ， toString 方 法 会 被 自动 调用 。(Java 1.5 发 行 版 
本 在 平台 中 增加 了 printf 方 法 ， 还 提供 了 包括 String.format 的 相关 方法 ， 与 C 语 言 中 的 sprintf 相 似 。) 


如 果 为 PhoneNumber 提 供 了 好 的 toString 方 法 ， 那么 ， 要 产生 有 用 的 诊断 消息 会 非常 容易 ， 


System.out.printIn("Failed to connect: ”+ phoneNumber); 


不 管 是 否 覆盖 了 toString 方 法 ， 程序 员 都 将 以 这 种 方式 来 产生 诊断 消息 ， 但 是 如 果 没 有 覆 
盖 toString 方 法 ， 产生 的 消息 将 难以 理解 。 提供 好 的 toString 方 法 ， 不 仅 有 益 于 这 个 类 的 实例 ， 
同样 也 有 益 于 那些 包含 这 些 实例 的 引用 的 对 象 ， 特别 是 集合 对 象 。 打印 Map 时 有 下 面 这 两 条 消 
44: “Jenny=PhoneNumber@ 163b91” Fil “Jenny=(408) 867-5309”, 你 更 愿意 看 到 哪 一 个 ? 


在 实际 应 用 中 ， toString 方 法 应 该 返回 对 和 象 中 包含 的 所 有 值得 关注 的 信息 ， 璧 如 上 述 电话 
号 码 例子 那样 。 如 果 对 象 太 大 ， 或 者 对 象 中 包含 的 状态 信息 难以 用 字符 串 来 表达 ， 这 样 做 就 
有 点 不 切实 际 。 在 这 种 情况 下 ， toString 应 该 返回 一 个 摘要 信息 ， 例 如 “Manhattan white 
pages (1487536 listings)” 或 者 “Thread[main, 5, main]”。 理 想 情 况 下 ， 字符 串 应 该 是 自 描述 
的 (self-explanatory) ,* (Thread 例 子 不 满足 这 样 的 要 求 。) 


在 实现 toString 的 时 候 ， 必 须要 做 出 一 个 很 重要 的 决定 ， 是 否 在 文档 中 指定 返回 值 的 格式 。 
对 于 值 类 (value class), 比如 电话 号 码 类 、 和 矩阵 类 ， 也 建议 这 么 做 。 指定 格式 的 好 处 是 ， 它 
可 以 被 用 做 一 种 标准 的 、 明 确 的 、 适合 人 阅读 的 对 象 表示 法 。 这 种 表示 法 可 以 用 于 输入 和 输 
出 ， 以 及 用 在 永久 的 适合 于 人 类 阅读 的 数据 对 象 中 ， 例如 XML 文档 。 如 果 你 指定 了 格式 ， 最 
好 再 提供 一 个 相 匹配 的 静态 工厂 或 者 构造 器 ， 以 便 程 序 员 可 以 很 容易 地 在 对 象 和 它 的 字符 串 
表示 法 之 间 来 回转 换 。 Java 平 台 类 库 中 的 许多 值 类 都 采用 了 这 种 做 法 ， 包括 BigInteger、 
BigDecimal 和 绝 大 多 数 的 基本 类 型 包装 类 (boxed primitive class) , 
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指定 toString 返 回 值 的 格式 也 有 不 足 之 处 : 如 果 这 个 类 已 经 被 广泛 使 用 ， 一 旦 指定 格式 ， 
就 必须 始终 如 一 地 坚持 这 种 格式 。 程 序 员 将 会 编写 出 相应 的 代码 来 解析 这 种 字符 串 表 示 法 、 
产生 字符 串 表示 法 ， 以 及 把 字符 串 表 示 法 嵌入 到 持久 的 数据 中 。 如 果 将 来 的 发 行 版 本 中 改变 
了 这 种 表示 法 ， 就 会 破坏 他 们 的 代码 和 数据 ， 他 们 当然 会 抱怨 。 如 果 不 指定 格式 ， 就 可 以 保 
留 灵活 性 ， 便 于 在 将 来 的 发 行 版 本 中 增加 信息 ， 或 者 改进 格式 。 


无 论 你 是 否决 定 指定 格式 ， 都 应 该 在 文档 中 明确 地 表明 你 的 意图 。 如 果 你 要 指定 格式 ， 则 
应 该 严格 地 这 样 去 做 。 例 如 ， 下 面 是 第 9 条 中 PhoneNumber 类 的 toString 方 法 : 


[xx 
* Returns the string representation of this phone number. 
* The string consists of fourteen characters whose format 
æ is "(XXX) YYY-ZZZZ", where XXX is the area code, YYY is 
* the prefix, and ZZZZ is the line number. (Each of the 
* capital letters represents a single decimal digit.) 
* 
* If any of the three parts of this phone number is too small 
* to fill up its field, the field is padded with leading zeros. 
# For example, if the value of the line number is 123, the last 
+ four characters of the string representation will be "0123". 
* 
+ Note that there is a single space separating the closing 
* parenthesis after the area code from the first digit of the 
+ prefix. 
*/ 
@Override public String toString() { 
return String.format("(%03d) %03d-%04d", 
areaCode, prefix, lineNumber); 


} 
如 果 你 决定 不 指定 格式 ， 那 么 文档 注释 部 分 也 应 该 有 如 下 所 示 的 指示 信息 : 


[we 

* Returns a brief description of this potion. The exact details 
+ of the representation are unspecified and subject to change, 
* but the following may be regarded as typical: 
* 
* "[Potion #9: type=love, smell=turpentine, look=india ink]" 
*/ 

@Override public String toString() { ... } 


对 于 那些 依赖 于 格式 的 细节 进行 编程 或 者 产生 永久 数据 的 程序 员 ， 在 读 到 这 段 注 释 之 后 ， 
一 旦 格式 被 改变 ， 则 只 能 自己 承担 后 果 。 


无 论 是 否 指 定格 式 ， 都 为 toString 返 回 值 中 包含 的 所 有 信息 ,提供 一 种 编程 式 的 访问 途径 。 
例如 ，PhoneNumber 类 应 该 包含 针对 area code、prefix 和 line number 的 访问 方法 。 如 果 不 这 么 
做 ， 就 会 迫使 那些 需要 这 些 信息 的 程序 员 不 得 不 自己 去 解析 这 些 字符 串 。 除 了 降低 了 程序 的 
性 能 ， 使 得 程序 员 们 去 做 这 些 不 必要 的 工作 之 外 ， 这 个 解析 过 程 也 很 容易 出 错 ， 会 导致 系统 
不 稳定 ， 如 果 格 式 发 生变 化 ， 还 会 导致 系统 崩 涡 。 如 果 没 有 提供 这 些 访问 方法 ， 即 使 你 已 经 
指明 了 字符 串 的 格式 是 可 以 变化 的 ， 这 个 字符 串 格 式 也 成 了 事实 上 的 API。 
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Cloneable 接 口 的 目的 是 作为 对 象 的 一 个 mixin 接 口 (mixin interface) ( 见 第 18 条 )， 表 明 
这 样 的 对 象 允 许 克 隆 (clone), 。 遗 憾 的 是 ， 它 并 没有 成 功 地 达到 这 个 目的 。 其 主要 的 缺陷 在 于 ， 
它 缺 少 一 个 clone 方 法 ，Object 的 clone 方 法 是 受 保护 的 。 如 果 不 借助 于 反射 (reflection) (i 
第 53 条 ) ， 就 不 能 仅仅 因为 一 个 对 象 实现 了 Cloneable， 就 可 以 调用 clone 方 法 。 即 使 是 反射 调 
用 也 可 能 会 失败 ， 因 为 不 能 保证 该 对 象 一 定 具 有 可 访问 的 clone 方 法 。 尽 管 存 在 这 样 那样 的 缺 
陷 ， 这 项 设施 仍然 被 广泛 地 使 用 着 ， 因 此 值得 我 们 进一步 地 了 解 。 本 条 目 将 告诉 你 如 何 实现 
一 个 行为 良好 的 clone 方 法 ， 并 讨论 何 时 适合 这 样 做 ， 同 时 也 简单 地 讨论 了 其 他 的 可 替换 做 法 。 


既然 Cloneable 并 没有 包含 任何 方法 ， 那 么 它 到 底 有 什么 作用 呢 ? 它 决 定 了 Object 中 受 保 
护 的 clone 方 法 实现 的 行为 : 如 果 一 个 类 实现 了 Cloneable，Object 的 clone 方 法 就 返回 该 对 象 的 
逐 域 拷贝 ， 否 则 就 会 抛 出 CloneNotSupportedException 异 常 。 这 是 接口 的 一 种 极端 非典 型 的 用 
法 ， 也 不 值得 仿效 。 通 常情 况 下 ， 实 现 接口 是 为 了 表明 类 可 以 为 它 的 客户 做 些 什 么 。 然 而 ， 
对 于 Cloneable 接 口 ， 它 改变 了 超 类 中 受 保护 的 方法 的 行为 。 


如 果实 现 Cloneable 接 口 是 要 对 某 个 类 起 到 作用 ， 类 和 它 的 所 有 超 类 都 必须 遵守 一 个 相当 
复杂 的 、 不 可 实施 的 ， 并 且 基 本 上 没有 文档 说 明 的 协议 。 由 此 得 到 一 种 语言 之 外 的 
(extralinguistic) 机 制 : 无 需 调用 构造 器 就 可 以 创建 对 象 。 


Clone 方 法 的 通用 约定 是 非常 弱 的 ， 下 面 是 来 自 java.lang.Object 规 范 中 的 约定 内 容 
[JavaSE6] 


创建 和 返回 该 对 象 的 一 个 拷贝 。 这 个 “拷贝 ”的 精确 含义 取决 于 该 对 象 的 类 。 一 般 的 含义 
是 ， 对 于 任何 对 象 5， 表 达 式 


x.clone() != x 

将 会 是 true， 并 且 ， 表达 式 

x.clone().getClass() == x.getClass() 

将 会 是 true， 但 这 些 都 不 是 绝对 的 要 求 。 虽 然 通常 情况 下 ， 表 达 式 
x.clone().equals(x) 


将 会 是 true， 但 是 ， 这 也 不 是 一 个 绝对 的 要 求 。 拷 贝 对 象 往往 会 导致 创建 它 的 类 的 一 个 新 
实例 ， 但 它 同 时 也 会 要 求 拷贝 内 部 的 数据 结构 。 这 个 过 程 中 没有 调用 构造 器 。 
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这 个 约定 存在 几 个 问题 。 “不 调用 构造 器 ” 的 规定 太 强 硬 了 。 行为 良好 的 clone 方 法 可 以 
调用 构造 器 来 创建 对 象 ， 构 造 之 后 再 复制 内 部 数据 。 如 果 这 个 类 是 final 的 ，clone 甚 至 可 能 会 
返回 一 个 由 构造 器 创建 的 对 象 。 


然而 ， “x.clone().getClass0 〇 通常 应 该 等 同 于 x.getClass()” 的 规定 又 太 软 弱 了 。 在 实践 
中 ， 程 序 员 会 假设 : 如 果 他 们 扩展 了 一 个 类 ， 并 且 从 子 类 中 调用 了 super.clone， 返 回 的 对 象 就 
将 是 该 子 类 的 实例 。 超 类 能 够 提供 这 种 功能 的 唯一 途径 是 ， 返 回 一 个 通过 调用 super.clone 而 得 
到 的 对 象 。 如 果 clone 方 法 返回 一 个 由 构造 器 创建 的 对 象 ， 它 就 得 到 有 错误 的 类 。 因 此 ， 如 果 
你 徐 盖 了 非 final 类 中 的 clone 方 法 ， 则 应 该 返回 一 个 通过 调用 super.clone 而 得 到 的 对 象 。 如 果 
类 的 所 有 超 类 都 遵守 这 条 规则 ， 那 么 调用 super.clone 最 终 会 调用 Object 的 clone 方 法 ， 从 而 创 
建 出 正确 类 的 实例 。 这 种 机 制 大 体 上 类 似 于 自动 的 构造 器 调用 链 ， 只 不 过 它 不 是 强制 要 求 的 。 


从 1.6 发 行 版 本 开始 ，Cloneable 接 口 并 没有 清楚 地 指明 ， 一 个 类 在 实现 这 个 接口 时 应 该 承 
担 哪 些 责 任 。 实 际 上 ， 对 于 实现 了 Cloneable 的 类 ， 我 们 总 是 期 望 它 也 提供 一 个 功能 适当 的 公 
有 的 clone 方法 。 通 常情 况 下 ， 除 非 该 类 的 所 有 超 类 都 提供 了 行为 良好 的 clone 实 现 ， 无 论 是 公 
有 的 还 是 受 保护 的 ， 否 则 ， 都 不 可 能 这 么 做 。 


假设 你 希望 在 一 个 类 中 实现 Cloneable， 并 且 它 的 超 类 都 提供 行为 良好 的 clone 方 法 。 你 从 
super.clone() 中 得 到 的 对 象 可 能 会 接近 于 最 终 要 返回 的 对 象 ， 也 可 能 相差 甚 远 ， 这 要 取决 于 这 
个 类 的 本 质 。 从 每 个 超 类 的 角度 来 看 ， 这 个 对 象 将 是 原始 对 象 功能 完整 的 克隆 (clone)。 在 这 
个 类 中 声明 的 域 (如 果 有 的 话 ) 将 等 同 于 被 克隆 对 象 中 相应 的 域 。 如 果 每 个 域 包 含 一 个 基本 
类 型 的 值 ， 或 者 包含 一 个 指向 不 可 变 对 象 的 引用 ， 那 么 被 返回 的 对 象 则 可 能 正 是 你 所 需要 的 
对 象 ， 在 这 种 情况 下 不 需要 再 做 进一步 处 理 。 例 如 ， 第 9 条 中 的 PhoneNumber 类 正 是 如 此 。 在 
这 种 情况 下 ， 你 所 需要 做 的 ， 除 了 声明 实现 了 Cloneable 之 外 ， 就 是 对 Object 中 受 保护 的 clone 
方法 提供 公有 的 访问 途径 : 

@Override public PhoneNumber clone() { 

rr Mas (PhoneNumber) super.clone(); 
} catch(CloneNotSupportedException e) { 
throw new AssertionError(); // Can't happen 


} 
} 


注意 上 述 的 clone 方 法 返回 的 是 PhoneNumber， 而 不 是 返回 Object。 从 Java 1.5 发 行 版 本 开 
始 ， 这 么 做 是 合法 的 ， 也 是 我 们 所 期 待 的 ， 因 为 1.5 发 行 版 本 中 引 太 了 协 变 返回 类 型 
(covariant return type) 作为 泛 型 。 换 句 话 说 ， 目 前 覆盖 方法 的 返回 类 型 可 以 是 被 覆盖 方法 
的 返回 类 型 的 子 类 了 。 这 样 有 助 于 覆盖 方法 提供 更 多 关于 被 返回 对 象 的 信息 ， 并 且 在 客户 端 
中 不 必 进 行 转换 。 由 于 Object.clone 返 回 Object，PhoneNumber.clone 必 须 在 返回 super.clone() 
的 结果 之 前 将 它 转换 。 这 里 体现 了 一 条 通则 : 永远 不 要 让 客户 去 做 任何 类 库 能 够 蔡 客 户 完成 
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的 事情 。 


如 果 对 象 中 包含 的 域 引 用 了 可 变 的 对 象 ， 使 用 上 述 这 种 简单 的 clone 实 现 可 能 会 导致 灾难 
性 的 后 果 。 例 如 ， 考 虑 第 6 条 中 的 Stack 类 : 


public class Stack { 
private Object[] elements; 
private int size = 0; 
private static final int DEFAULT_INITIAL_CAPACITY = 16; 


public StackQ) { 
this.elements = new Object (DEFAULT_INITIAL_CAPACITY]; 


public void push(Object e) { 
ensureCapacity(); 
elements[size++] = e; 


public Object pop() { 
if (size == @) 
throw new EmptyStackException(); 
Object result = elements[--size]; 
elements[size] = null; // Eliminate obsolete reference 
return result; 


// Ensure space for at least one more element. 
private void ensureCapacity() { 
if (elements. length == size) 
elements = Arrays.copyOf(elements, 2 * size + 1); 
} 


} 


假设 你 希望 把 这 个 类 做 成 可 克隆 的 (cloneable) 。 如 果 它 的 clone 方 法 仅仅 返回 Super. 
clone()， 这 样 得 到 的 Stack 实 例 ， 在 其 size 域 中 具有 正确 的 值 ， 但 是 它 的 elements 域 将 引用 与 原 
始 Stack 实 例 相同 的 数组 。 修 改 原始 的 实例 会 破坏 被 克隆 对 象 中 的 约束 条 件 ， 反 之 亦 然 。 很 快 
你 就 会 发 现 ， 这 个 程序 将 产生 毫 无 意义 的 结果 ， 或 者 抛 出 NullPointerException 异 常 。 


如 果 调 用 Stack 类 中 唯一 的 构造 器 ， 这 种 情况 就 永远 不 会 发 生 。 实 际 上 ，clone 方 法 就 是 另 
一 个 构造 器 ; 你 必须 确保 它 不 会 伤害 到 原始 的 对 象 ， 并 确保 正确 地 创建 被 克隆 对 象 中 的 约束 
条 件 (invariant)。 为 了 使 Stack 类 中 的 clone 方 法 正常 地 工作 ， 它 必须 要 拷贝 栈 的 内 部 信息 。 
最 容易 的 做 法 是 ， 在 elements 数 组 中 递归 地 调用 clone: 


@Override public Stack clone() { 
try { 
Stack result = (Stack) super.clone(); 
result.elements = elements.clone(); 
return result; 
} catch (CloneNotSupportedException e) { 
throw new AssertionError(); 
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注意 ， 我 们 不 一 定 要 将 elements.clone() 的 结果 转换 成 Object[]。 自 Java 1.5 发 行 版 本 起 ， 
在 数组 上 调用 clone 返 回 的 数组 ， 其 编译 时 类 型 与 被 克隆 数组 的 类 型 相同 。 


还 要 注意 ， 如 果 elements 域 是 final 的 ， 上 述 方案 就 不 能 正常 工作 ， 因 为 clone 方 法 是 被 禁 
止 给 elements 域 赋 新 值 的 。 这 是 个 根本 的 问题 :clone 架构 与 引用 可 变 对 象 的 final 域 的 正常 用 
法 是 不 相 兼 容 的 ， 除 非 在 原始 对 象 和 克隆 对 象 之 间 可 以 安全 地 共享 此 可 变 对 象 。 为 了 使 类 成 
为 可 克隆 的 ， 可 能 有 必要 从 某 些 域 中 去 掉 final 修 饰 符 。 


递归 地 调用 clone 有 时 还 不 够 。 例 如 ， 假 设 你 正在 为 一 个 散 列表 编写 clone 方 法 ， 它 的 内 部 
数据 包含 一 个 散 列 桶 数组 ， 每 个 散 列 桶 都 指向 “ 键 一 值 ”对 链表 的 第 一 个 项 ， 如 果 桶 是 空 的 ， 
则 为 null。 出 于 性 能 方面 的 考虑 ， 该 类 实现 了 它 自己 的 轻 量 级 单 向 链表 ， 而 没有 使 用 Java 内 部 
的 java.util.LinkedList。 该 类 如 下 : 


public class HashTable implements Cloneable { 
private Entry[] buckets = ...; 
private static class Entry { 
final Object key; 
Object value; 
Entry next; 


Entry(Object key, Object value, Entry next) { 
this.key = key; 
this.value = value; 
this.next = next; 


.. // Remainder omitted 


假设 你 仅仅 递归 地 克隆 这 个 散 列 桶 数组 ， 就 像 我 们 对 Stack 类 所 做 的 那样 : 


// Broken - results in shared internal state! 
@Override public HashTable clone() { 
try { 
HashTable result = (HashTable) super.clone(); 
result.buckets = buckets.clone(); 
return result; 
} catch (CloneNotSupportedException e) { 
throw new AssertionError(); 
} 


} 


虽然 被 克隆 对 象 有 它 自己 的 散 列 桶 数组 , 但 是 , 这 个 数组 引用 的 链表 与 原始 对 象 是 一 样 的 ， 
从 而 很 容易 引起 克隆 对 象 和 原始 对 象 中 不 确定 的 行为 。 为 了 修正 这 个 问题 ， 必 须 单独 地 拷贝 
并 组 成 每 个 桶 的 链表 。 下 面 是 一 种 常见 的 做 法 : 


public Class HashTable implements Cloneable { 
private Entry[] buckets = ...; 
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private static class Entry { 
final Object key; 
Object value; 
Entry next; 


Entry(Object key, Object value, Entry next) { 
this.key = key; 
this.value = value; 
this.next = next; 


} 
// Recursively copy the linked list headed by this Entry 
Entry deepCopy() { 
return new Entry(key, value, 
next == null ? null : next.deepCopy()); 


} 

} 

@Override public HashTable clone() { 
try { 


HashTable result = (HashTable) super.clone(); 
result.buckets = new Entry[buckets. length]; 
for Cint i = 0; i < buckets. length; i++) 

if (buckets[i] != null) 

result.buckets[i] = buckets[i].deepCopy(); 
return result; 
} catch (CloneNotSupportedException e) { 

throw new AssertionError(); 


.. // Remainder omitted 


} 


私有 类 HashTable.Entry 被 加 强 了 ， 它 支持 一 个 “深度 拷贝 (deep copy)” Fre. HashTable 
上 的 clone 方 法 分 配 了 一 个 大 小 适中 的 、 新 的 buckets 数 组 ， 并 且 遍 历 原 始 的 buckets 数 组 ， 对 每 
一 个 非 空 散 列 桶 进行 深度 拷贝 。Entry 类 中 的 深度 拷贝 方法 递归 地 调用 它 自身 ， 以 便 拷贝 整个 
链表 ( 它 是 链表 的 头 节 点 )。 虽 然 这 种 方法 很 灵活 ， 如 果 散 列 桶 不 是 很 长 的 话 ， 也 会 工作 得 很 
好 ， 但是， 这 样 克隆 一 个 链表 并 不 是 一 种 好 办 法 ， 因 为 针对 列表 中 的 每 个 元 素 ， 它 都 要 消耗 
一 段 栈 空间 。 如 果 链 表 比 较 长 ， 这 很 容易 导致 栈 溢 出 。 为 了 避免 发 生 这 种 情况 ,你 可 以 在 
deepCopy 中 用 迭代 (iteration) 代替 递归 (recursion) ; 


// Iteratively copy the linked list headed by this Entry 
Entry deepCopy() { 
Entry result = new Entry(key, value, next); 


for (Entry p = result; p.next != null; p = p.next) 
p.next = new Entry(p.next.key, p.next.value, p.next.next); 


return result; 


克隆 复杂 对 象 的 最 后 一 种 办 法 是 ， 先 调用 super.clone ， 然 后 把 结果 对 象 中 的 所 有 域 都 设置 
成 它们 的 空白 状态 (virgin state) ， 然 后 调用 高 层 (higher-level) 的 方法 来 重新 产生 对 象 的 状 
态 。 在 我 们 的 HashTable 例 子 中 ，buckets 域 将 被 初始 化 为 一 个 新 的 散 列 桶 数组 ， 然 后 ， 对 于 正 
在 被 克隆 的 散 列表 中 的 每 一 个 键 一 值 映射 ， 都 调用 put (key, value) 方法 (上 面 没有 给 出 其 代 
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码 )。 这 种 做 法 往往 会 产生 一 个 简单 、 合 理 且 相 当 优 美的 clone 方 法 ,但 是 它 运行 起 来 通常 没有 
“直接 操作 对 象 及 其 克隆 对 象 的 内 部 状态 的 clone 方 法 ” 快 。 


如 同 构造 器 一 样 ，clone 方 法 不 应 该 在 构造 的 过 程 中 ， 调 用 新 对 象 中 任何 非 final 的 方法 
( 见 第 17 条 )。 如 果 clone 调 用 了 一 个 被 覆盖 的 方法 ， 那 么 在 该 方法 所 在 的 子 类 有 机 会 修正 它 在 
克隆 对 象 中 的 状态 之 前 ， 该 方法 就 会 先 被 执行 ， 这 样 很 有 可 能 会 导致 克隆 对 象 和 原始 对 象 之 
间 的 不 一 致 。 因 此 ， 上 一 段落 中 讨论 到 的 put(key, value) 方 法 应 该 要 么 是 final 的 ， 要 么 是 私有 
的 (如 果 是 私有 的 ， 它 应 该 算是 非 final 公 有 方法 的 “辅助 方法 [helper method)” )。 


Object 的 clone 方 法 被 声明 为 可 抛 出 CloneNotSupportedException 异 常 ， 但 是 ,覆盖 版 本 的 
clone 方 法 可 能 会 忽略 这 个 声明 。 公 有 的 clone 方 法 应 该 省 略 这 个 声明 ， 因 为 不 会 抛 出 受 检 异 常 
(checked exception) 的 方法 与 会 抛 出 异常 的 方法 相 比 ， 使 用 起 来 更 加 轻松 ( 见 第 59 条 )。 如 
果 专 门 为 了 继承 而 设计 的 类 [ 见 第 17 条 ] 覆盖 了 clone 方 法 ， 覆 盖 版 本 的 clone 方 法 就 应 该 模拟 
Object.clone 的 行为 : 它 应 该 被 声明 为 protected、 抛 出 CloneNotSupportedException 异 常 ， 并 
且 该 类 不 应 该 实现 Cloneable 接 口 。 这样 做 可 以 使 子 类 具有 实现 或 不 实现 Cloneable 接 口 的 自由 ， 
就 仿佛 它们 直接 扩展 了 Object 一 样 。 


还 有 一 点 值得 注意 。 如 果 你 决定 用 线程 安全 的 类 实现 Cloneable 接 口 ， 要 记得 它 的 clone 方 
法 必须 得 到 很 好 的 同步 ， 就 像 任何 其 他 方法 一 样 ( 见 第 66 条 ) 。Object 的 clone 方 法 没有 同步 ， 
因此 即使 很 满意 ， 可 能 也 必须 编写 同步 的 clone 方 法 来 调用 super.clone()。 


简 而 言 之 ， 所 有 实现 了 Cloneable 接 口 的 类 都 应 该 用 一 个 公有 的 方法 覆盖 clone。 此 公有 方 
法 首先 调用 super.clone， 然 后 修正 任何 需要 修正 的 域 。 一 般 情 况 下 ， 这 意味 着 要 拷贝 任何 包含 
内 部 “深层 结构 ”的 可 变 对 象 ， 并 用 指向 新 对 象 的 引用 代替 原来 指向 这 些 对 象 的 引用 。 虽 然 ， 
这 些 内 部 拷贝 操作 往往 可 以 通过 递归 地 调用 clone 来 完成 ， 但 这 通常 并 不 是 最 佳 方法 。 如 果 该 
类 只 包含 基本 类 型 的 域 ， 或 者 指向 不 可 变 对 象 的 引用 ， 那 么 多 半 的 情况 是 没有 域 需 要 修正 。 
这 条 规则 也 有 例外 ， 辟 如， 代表 序列 号 或 其 他 唯一 ID 值 的 域 ， 或 者 代表 对 象 的 创建 时 间 的 域 ， 
不 管 这 些 域 是 基本 类 型 还 是 不 可 变 的 ， 它 们 也 都 需要 被 修正 。 


~ 


真 的 有 必要 这 么 复杂 吗 ? 很 少 有 这 种 必要 。 如 果 你 扩展 一 个 实现 了 Cloneable 接 口 的 类 ， 
那么 你 除了 实现 一 个 行为 良好 的 clone 方 法 外 ， 没 有 别 的 选择 。 否 则 ， 有 最 好 提供 某 些 其 他 的 途 
径 来 代替 对 象 描 贝 ， 或 者 干脆 不 提供 这 样 的 功能 。 例 如 ， 对 于 不 可 变 类 ， 支 持 对 象 拷贝 并 没 ， 
有 太 大 的 意义 ， 因 为 被 拷贝 的 对 象 与 原始 对 象 并 没有 实质 的 不 同 。 


另 一 个 实现 对 象 拷贝 的 好 办 法 是 提供 一 个 拷贝 构造 器 (copy constructor) 或 描 贝 工厂 
(copy factory)。 拷 贝 构造 器 只 是 一 个 构造 器 ， 它 唯一 的 参数 类 型 是 包含 该 构造 器 的 类 ， 
例如 : 
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public Yum(Yum yum); 


拷贝 工厂 是 类 似 于 拷贝 构造 器 的 静态 工厂 : 


public static Yum newInstance(Yum yum) ; 


拷贝 构造 器 的 做 法 , 及 其 静态 工厂 方法 的 变形 , 都 比 Cloneable/clone 方 法 具有 更 多 的 优势 
它们 不 依赖 于 某 一 种 很 有 风险 的 、 语 言 之 外 的 对 象 创建 机 制 ， 它 们 不 要 求 遵 守 尚 未 制定 好 文 
档 的 规范 ， 它 们 不 会 与 final 域 的 正常 使 用 发 生 冲 突 ， 它们 不 会 抛 出 不 必要 的 受 检 异 常 
(checked exception) ， 它们 不 需要 进行 类 型 转换 。 虽 然 你 不 可 能 把 拷贝 构造 器 或 者 静态 工厂 
放 到 接口 中 ,但 是 由 于 Cloneable 接 口 缺少 一 个 公有 的 clone 方 法 ， 所 以 它 也 没有 提供 一 个 接口 
该 有 的 功能 。 因 此 ， 使 用 拷贝 构造 器 或 者 拷贝 工厂 来 代替 clone 方 法 时 ， 并 没有 放弃 接口 的 功 
能 特性 。 


更 进一步 ， 拷 贝 构造 器 或 者 拷贝 工厂 可 以 带 一 个 参数 ， 参 数 类 型 是 通过 该 类 实现 的 接口 。 
例如 ， 按 照 惯例 ， 所 有 通用 集合 实现 都 提供 了 一 个 拷贝 构造 器 ， 它 的 参数 类 型 为 Collection 或 
者 Map。 基 于 接口 的 拷贝 构造 器 和 拷贝 工厂 (更 准确 的 叫 法 应 该 是 “转换 构造 器 (conversion 
constructor) ”和 转换 工厂 (conversion factory))， 人 允许 客户 选择 拷贝 的 实现 类 型 ， 而 不 是 强 
迫 客户 接受 原始 的 实现 类 型 。 例 如 ,假设 你 有 一 个 HashSet, 并且 希 望 把 它 拷贝 成 一 个 TreeSet。 
clone 方 法 无 法 提供 这 样 的 功能 ， 但 是 用 转换 构造 器 很 容易 实现 : new TreeSet(s)。 


既然 Cloneable 具 有 上 述 那 么 多 问题 ， 可 以 肯定 地 说 ， 其 他 的 接口 都 不 应 该 扩展 (extend) 
这 个 接口 ， 为 了 继承 而 设计 的 类 ( 见 第 17 条 ) 也 不 应 该 实现 (implement) 这 个 接口 。 由 于 它 
具有 这 么 多 缺点 ， 有 些 专家 级 的 程序 员 干脆 从 来 不 去 覆盖 clone 方 法 ， 也 从 来 不 去 调用 它 ， 除 
非 拷贝 数组 。 你 必须 清楚 一 点 ， 对 于 一 个 专门 为 了 继承 而 设计 的 类 ， 如 果 你 未 能 提供 行为 良 
好 的 受 保护 的 (Protected) clone 方 法 ， 它 的 子 类 就 不 可 能 实现 Cloneable 接 口 。 
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与 本 章 中 讨论 的 其 他 方法 不 同 ，compareTo 方 法 并 没有 在 Object 中 声明 。 相 反 ， 它 是 
Comparable 接 口中 唯一 的 方法 。compareTo 方 法 不 但 允许 进行 简单 的 等 同性 比较 ， 而 且 人 允许 执 
行 顺序 比较 ， 除 此 之 外 ， 它 与 Object 的 equals 方 法 具有 相似 的 特征 ， 它 还 是 个 泛 型 。 类 实现 了 
Comparable 接 口 ， 就 表明 它 的 实例 具有 内 在 的 排序 关系 (natural ordering) 。 为 实现 
Comparable 接 口 的 对 象 数组 进行 排序 就 这 么 简单 ; 


Arrays.sort(a); 


对 存储 在 集合 中 的 Comparable 对 象 进行 搜索 、 计 算 极 限 值 以 及 自动 维护 也 同样 简单 。 例 
如 ;下 面 的 程序 依赖 于 String 实 现 了 Comparable 接 口 , 它 去 掉 了 命令 行 参数 列表 中 的 重复 参数 ， 
并 按 字 母 顺序 打印 出 来 : 

public class WordList { 

public static void main(String[] args) { 
Set<String> s = new TreeSet<String>(); 
Collections.addAll{s, args); 
System.out.printIn(s); 

} 

一 旦 类 实现 了 Comparable 接 口 ， 它 就 可 以 跟 许 多 泛 型 算法 (generic algorithm) 以 及 依赖 
于 该 接口 的 集合 实现 (collection implementation) 进行 协作 。 你 付出 很 小 的 努力 就 可 以 获得 
非常 强大 的 功能 。 事 实 上 ，Java 平 台 类 库 中 的 所 有 值 类 (value classes) 都 实现 了 Comparable 
接口 。 如 果 你 正在 编写 一 个 值 类 ， 它 具有 非常 明显 的 内 在 排序 关系 ， 比 如 按 字母 顺序 、 按 数 
值 顺序 或 者 按 年 代 顺 序 ， 那 你 就 应 该 坚决 考虑 实现 这 个 接口 : 


public interface Comparable<T> { 
int compareTo(T t); 


compareTo 方 法 的 通用 约定 与 equals 方 法 的 相似 : 


将 这 个 对 象 与 指定 的 对 象 进行 比较 。 当 该 对 象 小 于 、 等 于 或 大 于 指定 对 象 的 时 候 ， 分 别 返 
回 一 个 负 整 数 、 零 或 者 正 整数 。 如 果 由 于 指定 对 象 的 类 型 而 无 法 与 该 对 象 进行 比较 ， 则 抛 出 
ClassCastException 异 常 。 


在 下 面 的 说 明 中 ， 符 号 sgn (AKA) 表示 数学 中 的 signum 函 数 ， 它 根据 表达 式 
(expression) 的 值 为 负 值 、 零 和 正 值 ， 分 别 返回 一 1、0 或 1。 
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。 实 现 者 必须 确保 所 有 的 x 和 y 都 满足 sgn(x.compareTo(y)) == -sgn (y.compareTo(x)), GX 
也 瞳 示 着 ， 当 且 仅 当 y.compareTo(x) 抛 出 异常 时 ，x.compareTo(y) 才 必须 抛 出 异常 。) 


"实现 者 还 必须 确保 这 个 比较 关系 是 可 传递 的 : (x.compareTo(y) > 0 && ycompareTo(z) 
> 0) 暗示 着 x.compareTo(z) > 0。 


“ 最后， 实现 者 必须 确保 x.compareTo(y) == 0 上 暗示 着 所 有 的 z 都 满足 sgn(x. compareTo(z)) 
== sgn(y.compareTo(z)), 


© 5h 2 dt i (x.compareTo(y) == 0) == (x.equals(y))， 但 这 并 非 绝对 必要 。 一 般 说 来 ， 任 何 
实现 了 Comparable 接 口 的 类 ， 若 违反 了 这 个 条 件 ， 都 应 该 明确 予以 说 明 。 推 荐 使 用 这 样 
的 说 法 :“ 注 意 : 该 类 具有 内 在 的 排序 功能 ， 但 是 与 equals 不 一 致 。” 


千 万 不 要 被 上 述 约 定 中 的 数学 关系 所 迷惑 。 如 同 equals 约 定 ( 见 第 8 条 ) 一 样 ，compareTo 
约定 并 没有 它 看 起 来 的 那么 复杂 。 在 类 的 内 部 ， 任 何 合理 的 顺序 关系 都 可 以 满足 compareTo 约 
定 。 与 equals 不 同 的 是 ， 在 跨越 不 同类 的 时 候 ，compareTo 可 以 不 做 比较 :如果 两 个 被 比较 的 
对 象 引用 不 同类 的 对 象 ，compareTo 可 以 抛 出 ClassCastException 异 常 。 通 常 ， 这 正 是 
compareTo 在 这 种 情况 下 应 该 做 的 事情 ， 如 果 类 设置 了 正确 的 参数 ,这 也 正 是 它 所 要 做 的 事情 。 
虽然 以 上 约定 并 没有 把 跨 类 之 间 的 比较 排除 在 外 ， 但 是 从 Java 1. .6 发 行 版 本 开始 ， Java 平 台 类 
库 中 就 没有 哪个 类 有 支持 这 种 特性 了 。 


就 好 像 违 反 了 hashCode 约 定 的 类 会 破坏 其 他 依赖 于 散 列 做 法 的 类 一 样 ， 违 反 compareTo 约 
定 的 类 也 会 破坏 其 他 依赖 于 比较 关系 的 类 。 依 赖 于 比较 关系 的 类 包括 有 序 集合 类 TreeSet 和 
TreeMap， 以 及 工具 类 Collections 和 Arrays， 它们 内 部 包含 有 搜索 和 排序 算法 。 


现在 我 们 来 回顾 一 下 compareTo 约 定 中 的 条 款 。 第 一 条 指出 ， 如 果 颠 倒 了 两 个 对 象 引 用 之 
间 的 比较 方向 ， 就 会 发 生 下 面 的 情况 : 如 果 第 一 个 对 象 小 于 第 二 个 对 象 ， 则 第 二 个 对 象 一 定 
大 于 第 一 个 对 象 ， 如 果 第 一 个 对 象 等 于 第 二 个 对 象 ， 则 第 二 个 对 象 一 定 等 于 第 三 个 对 象 ， 如 
果 第 一 个 对 象 大 于 第 二 个 对 象 ， 则 第 二 个 对 象 一 定 小 于 第 一 个 对 象 。 第 二 条 指出 ， 如 果 一 个 
对 象 大 于 第 二 个 对 象 ， 并 且 第 二 个 对 象 又 大 于 第 三 个 对 象 ， 那 么 第 一 个 对 象 一 定 大 于 第 三 个 
对 象 。 最 后 一 条 指出 ， 在 比较 时 被 认为 相等 的 所 有 对 象 ， 它 们 跟 别 的 对 象 做 比较 时 一 TURR 
生 同 样 的 结果 。 


这 三 个 条 款 的 一 个 直接 结果 是 ， 由 compareTo 方 法 施加 的 等 同性 测试 (equality test), ， 也 
一 定 遵 守 相 同 于 equals 约 定 所 施加 的 限制 条 件 : 自 反 性 、 对 称 性 和 传递 性 。 因 此 ， 下 面 的 告诫 
也 同样 适用 : 无 法 在 用 新 的 值 组 件 扩展 可 实例 化 的 类 时 ， 同 时 保持 compareTo 约 定 ， 除 非 愿 意 
放弃 面向 对 象 的 抽象 优势 ( 见 第 8 条 )。 针 对 equals 的 权宜 之 计 也 同样 适用 于 compareTo 方 法 。 
如 果 你 想 为 一 个 实现 了 Comparable 接 口 的 类 增加 值 组 件 ， 请 不 要 扩展 这 个 类 ， 而 是 要 编写 一 
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个 不 相关 的 类 ， 其 中 包含 第 一 个 类 的 一 个 实例 。 然 后 提供 一 个 “视图 (view)” 方 法 返回 这 个 
实例 。 这 样 既 可 以 让 你 自由 地 在 第 二 个 类 上 实现 compareTo 方 法 ， 同 时 也 允许 它 的 客户 端 在 必 
要 的 时 候 ， 把 第 二 个 类 的 实例 视 同 第 一 个 类 的 实例 。 


compareTo 约 定 的 最 后 一 段 是 一 个 强烈 的 建议 ， 而 不 是 真正 的 规则 ， 只 是 说 明了 compareTo 
方法 施加 的 等 同性 测试 ， 在 通常 情况 下 应 该 返回 与 equals 方 法 同样 的 结果 。 如 果 遵 守 了 这 一 条 ， 
那么 由 compareTo 方 法 所 施加 的 顺序 关系 就 被 认为 “与 equals 一 致 (consistent with equals)”, 
如 果 违 反 了 这 条 规则 ， 顺 序 关系 就 被 认为 “与 equals 不 一 致 (inconsistent with equals)”, 41 
果 一 个 类 的 compareTo 方 法 施加 了 一 个 与 equals 方 法 不 一 致 的 顺序 关系 ， 它 仍然 能 够 正常 工作 ， 
但 是 ， 如 果 一 个 有 序 集合 (sorted collection) 包含 了 该 类 的 元 素 ， 这 个 集合 就 可 能 无 法 遵守 相 
应 集合 接口 (Collection、Set 或 Map) 的 通用 约定 。 这 是 因为 ， 对 于 这 些 接口 的 通用 约定 是 按 
照 equals 方 法 来 定义 的 ， 但 是 有 序 集合 使 用 了 由 compareTo 方 法 而 不 是 equals 方 法 所 施加 的 等 同 
性 测试 。 尽 管 出 现 这 种 情况 不 会 造成 灾难 性 的 后 果 ， 但 是 应 该 有 所 了 解 。 


例如 ， 考 虑 BigDecimal 类 ， 它 的 compareTo 方 法 与 equals 不 一 致 。 如 果 你 创建 了 一 个 
HashSet 实 例 ， 并 且 添 加 new BigDecimal ("1.0") 和 new BigDecimal ("1.00")， 这 个 集合 就 
将 包含 两 个 元 素 ， 因 为 新 增 到 集合 中 的 两 个 BigDecimal 实 例 ， 通 过 equals 方 法 来 比较 时 是 不 相 
等 的 。 然 而 ， 如 果 你 使 用 TreeSet 而 不 是 HashSet 来 执行 同样 的 过 程 ， 集 合 中 将 只 包含 一 个 元 素 ， 
因为 这 两 个 BigDecimal 实 例 在 通过 compareTo 方 法 进行 比较 时 是 相等 的 。( 详 情 请 参阅 
BigDecimal 的 文档 。) 


编写 compareTo 方 法 与 编写 equals 方 法 非常 相似 ， 但 也 存在 几 处 重大 的 差别 。 因 为 
Comparable 接 口 是 参 数 化 的 ， 而 且 comparable 方 法 是 静态 的 类 型 ， 因 此 不 必 进 行 类 型 检查 ， 
也 不 必 对 它 的 参数 进行 类 型 转 。 如 果 参 数 的 类 型 不 合适 ， 这 个 调用 甚至 无 法 编译 。 如 果 参 数 
为 null， 这 个 调用 应 该 抛 出 NullPointerException 异 常 ， 并 且 一 旦 该 方法 试图 访问 它 的 成 员 时 
就 应 该 抛 出 。 


CompareTo 方 法 中 域 的 比较 是 顺序 的 比较 ， 而 不 是 等 同性 的 比较 。 比 较 对 象 引用 域 可 以 是 
通过 递归 地 调用 compareTo 方 法 来 实现 。 如 果 一 个 域 并 没有 实现 Comparable 接 口 ， 或 者 你 需要 
使 用 一 个 非 标准 的 排序 关系 ， 就 可 以 使 用 一 个 显 式 的 Comparator 来 代替 。 或 者 编写 自己 的 
Comparator， 或 者 使 用 已 有 的 Comparator， 璧 如 针对 第 8 条 中 CaseInsensitiveString 类 的 这 个 
compareTo 方 法 使 用 一 个 已 有 的 Comparator ; 

public final class CaseInsensitiveString 

implements Comparable<CaseInsensitiveString> { 
public int compareTo(CaseInsensitiveString cis) { 


return String.CASE_INSENSITIVE_ORDER.compare(s, cis.s); 


... // Remainder omitted 
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注意 CaseInsensitiveString 类 实现 了 Comparable<CaseInsensitiveString> 接 口 。 由 此 可 见 ， 
CaselnsensitiveString 引 用 只 能 与 其 他 的 Comparable<CaseInsensitiveString> 引 用 进行 比较 。 
在 声明 类 去 实现 Comparable 接 口 时 ， 这 是 常用 的 模式 。 还 要 注意 compareTo 方 法 的 参数 是 
CaseInsensitiveString ， 而 不 是 Object。 这 是 上 述 的 类 声明 所 要 求 的 。 


比较 整数 型 基本 类 型 的 域 ， 可 以 使 用 关系 操作 符 < 和 > 。 例 如 ， 浮 点 域 用 Double. 
compare 或 者 Floatcompare， 而 不 用 关系 操作 符 ， 当 应 用 到 浮 点 值 时 ， 它 们 没有 遵守 
compareTo 的 通用 约定 。 对 于 数组 域 ， 则 要 把 这 些 指导 原则 应 用 到 每 个 元 素 上 。 


如 果 一 个 类 有 多 个 关键 域 ， 那 么 ， 按 什么 样 的 顺序 来 比较 这 些 域 是 非常 关键 的 。 你 必须 从 
最 关键 的 域 开 始 ， 逐 步 进 行 到 所 有 的 重要 域 。 如 果 某 个 域 的 比较 产生 了 非 零 的 结果 ( 零 代表 
相等 )， 则 整个 比较 操作 结束 ， 并 返回 该 结果 。 如 果 最 关键 的 域 是 相等 的 ， 则 进一步 比较 次 最 
关键 的 域 ， 以 此 类 推 。 如 果 所 有 的 域 都 是 相等 的 ， 则 对 象 就 是 相等 的 ， 并 返回 零 。 下 面 通过 
第 9 条 中 的 PhoneNumber 类 的 compareTo 方 法 来 说 明 这 种 方法 : 


public int compareTo(PhoneNumber pn) { 
// Compare area codes 
if (areaCode < pn.areaCode) 
return -1; 
if (areaCode > pn.areaCode) 
return 1 
// Area codes are equal, compare prefixes 
if (prefix < pn.prefix) 
return -1; 
if (prefix > pn.prefix) 
return 1; 


// Area codes and prefixes are equal, compare line numbers 
if ClineNumber < pn.1lineNumber) 

return -1; 
if ClineNumber > pn.lineNumber) 

return 1; 


return @; // All fields are equal 
} 


虽然 这 个 方法 可 行 ， 但 它 还 可 以 进行 改进 。 回 想 一 下 ，compareTo 方 法 的 约定 并 没有 指定 
返回 值 的 大 小 (magnitude)， 而 只 是 指定 了 返回 值 的 符号 。 你 可 以 利用 这 一 点 来 简化 代码 ， 
或 许 还 能 提高 它 的 运行 速度 : : 


public int compareTo(PhoneNumber pn) { 
// Compare area codes 
int areaCodeDiff = areaCode - pn.areaCode; 
if (areaCodeDiff != 0) 
return areaCodeDiff; 


// Area codes are equal, compare prefixes 
int prefixDiff = prefix - pn.prefix; 
if (prefixDiff != 0) 

return prefixDiff; 
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// Area codes and prefixes are equal, compare line numbers 
return lineNumber - pn.1]ineNumber; 


这 项 技巧 在 这 里 能 够 工作 得 很 好 ， 但 是 用 起 来 要 非常 小 心 。 除 非 你 确信 相关 的 域 不 会 为 负 
值 ， 或 者 更 一 般 的 情况 : 最 小 和 最 大 的 可 能 域 值 之 差 小 于 或 等 于 INTEGER.MAX_VALUE 
(23-1)， 否 则 就 不 要 使 用 这 种 方法 。 这 项 技巧 有 时 不 能 正常 工作 的 原因 在 于 ， 一 个 有 符号 的 32 
位 的 整数 还 没有 大 到 足以 表达 任意 两 个 32 位 整数 的 差 。 如 果 i 是 一 个 很 大 的 正 整 数 (int 类 型 )， 
而 j 是 一 个 很 大 的 负 整 数 (int 类 型 )， 那 么 (i-j) 将 会 溢出 ， 并 返回 一 个 负 值 。 这 样 就 使 得 
compareTo 方 法 将 对 某 些 参 数 返 回 错误 的 结果 ， 违 反 了 compareTo 约 定 的 第 一 条 和 第 二 条 。 这 
不 是 一 个 纯粹 的 理论 问题 ， 它 已 经 在 实际 的 系统 中 导致 了 失败 。 这 些 失 败 可 能 非常 难以 调试 ， 
因为 这 样 的 compareTo 方 法 对 于 大 多 数 的 输入 值 都 能 正常 工作 。 





第 4 章 
类 和 接口 


类 和 接口 是 Java 程 序 设计 语言 的 核心 ， 它 们 也 是 Java 语 言 的 基本 抽象 单元 。Java 语 言 提 
供 了 许多 强大 的 基本 元 素 ， 供 程序 员 用 来 设计 类 和 接口 。 本 章 阐述 的 一 些 指导 原则 ， 可 以 者 
助 你 更 好 地 利用 这 些 元 素 ， 设 计 出 更 加 有 用 、 健 壮 和 灵活 的 类 和 接口 。 


第 13 条 ， 使 类 和 成 员 的 可 访问 性 最 小 化 


要 区 别 设计 良好 的 模块 与 设计 不 好 的 模块 ， 最 重要 的 因素 在 于 ， 这 个 模块 对 于 外 部 的 其 他 
模块 而 言 ， 是 否 隐藏 其 内 部 数据 和 其 他 实现 细节 。 设 计 良 好 的 模块 会 隐藏 所 有 的 实现 细节 ， 
把 它 的 API 与 它 的 实现 清晰 地 隔离 开 来 。 然 后 ， 模 块 之 间 只 通过 它们 的 API 进 行 通信 ， 一 个 模 
块 不 需要 知道 其 他 模块 的 内 部 工作 情况 。 这 个 概念 被 称 为 信息 隐藏 (information hiding) 或 
封装 (encapsulation)， 是 软件 设计 的 基本 原则 之 一 [Parnas72]。 


信息 隐藏 之 所 以 非常 重要 有 许多 原因 ， 其 中 大 多 数理 由 都 源 于 这 样 一 个 事实 ， 它 可 以 有 效 
地 解除 组 成 系统 的 各 模块 之 间 的 耦合 关系 ， 使 得 这 些 模块 可 以 独立 地 开发 、 测 试 、 优 化、 使 
用 、 理 解 和 修改 。 这 样 可 以 加 快 系统 开发 的 速度 ， 因 为 这 些 模块 可 以 并 行 开发 。 它 也 减轻 了 
维护 的 负担 ， 因 为 程序 员 可 以 更 快 地 理解 这 些 模块 ， 并 且 在 调试 它们 的 时 候 可 以 不 影响 其 他 
的 模块 。 虽 然 信息 隐藏 本 身 无 论 是 对 内 还 是 对 外 ， 都 不 会 带 来 更 好 的 性 能 ， 但 是 它 可 以 有 效 
地 调节 性 能 : 一 旦 完成 一 个 系统 ， 并 通过 剖析 确定 了 哪些 模块 影响 了 系统 的 性 能 ( 见 第 55 条 )， 
那些 模块 就 可 以 被 进一步 优化 ， 而 不 会 影响 到 其 他 模块 的 正确 性 。 信 息 隐藏 提高 了 软件 的 可 
重用 性 ， 因 为 模块 之 间 并 不 紧密 相连 ， 除 了 开发 这 些 模块 所 使 用 的 环境 之 外 ， 它 们 在 其 他 的 
环境 中 往往 也 很 有 用 。 最 后 ， 信 息 隐藏 也 降低 了 构建 大 型 系统 的 风险 ， 因 为 即使 整个 系统 不 
可 用 ， 但 是 这 些 独立 的 模块 却 有 可 能 是 可 用 的 。 





Java 程 序 设计 语言 提供 了 许多 机 制 (facility) 来 协助 信息 隐藏 。 访 问 控制 (access 
control) 机 制 JLS, 6.6] 决 定 了 类 、 接 口 和 成 员 的 可 访问 性 (accessibility) 。 实 体 的 可 访问 性 
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是 由 该 实体 声明 所 在 的 位 置 ， 以 及 该 实体 声明 中 所 出 现 的 访问 修饰 符 (private, protected Ai 
public) 共同 决定 的 。 正 确 地 使 用 这 些 修饰 符 对 于 实现 信息 隐藏 是 非常 关键 的 。 


第 一 规则 很 简单 ; 尽 可 能 地 使 每 个 类 或 者 成 员 不 被 外 界 访问 。 换 句 话说 ， 应 该 使 用 与 你 正 
在 编写 的 软件 的 对 应 功能 相 一 致 的 、 尽 可 能 最 小 的 访问 级 别 。 


对 于 顶层 的 〈 非 嵌 套 的 ) 类 和 接口 ， 只 有 两 种 可 能 的 访问 级 别 : 包 级 私有 的 (package- 
private) 和 公有 的 (public) 。 如 果 你 用 public 修 饰 符 声明 了 顶层 类 或 者 接口 ， 那 它 就 是 公有 
的 ， 否 则 ， 它 将 是 包 级 私有 的 。 如 果 类 或 者 接口 能 够 被 做 成 包 级 私有 的 ， 它 就 应 该 被 做 成 包 
级 私有 。 通 过 把 类 或 者 接口 做 成 包 级 私有 ， 它 实际 上 成 了 这 个 包 的 实现 的 一 部 分 ， 而 不 是 该 
包 导 出 的 API 的 一 部 分 ， 在 以 后 的 发 行 版 本 中 ， 可 以 对 它 进 行 修改 、 替 换 ， 或 者 删除 ， 而 无 需 
担心 会 影响 到 现 有 的 客户 端 程序 。 如 果 你 把 它 做 成 公有 的 ， 你 就 有 责任 永远 支持 它 ， 以 保持 
它们 的 兼容 性 。 


如 果 一 个 包 级 私有 的 顶层 类 (或 者 接口 ) 只 是 在 某 一 个 类 的 内 部 被 用 到 ， 就 应 该 考虑 使 它 
成 为 唯一 使 用 它 的 那个 类 的 私有 赚 套 类 ( 见 第 22 条 )。 这 样 可 以 将 它 的 可 访问 范围 从 包 中 的 所 
有 类 缩小 到 了 使 用 它 的 那个 类 。 然 而 ， 降 低 不 必要 公有 类 的 可 访问 性 ， 比 降低 包 级 私有 的 顶 
层 类 的 更 重要 得 多 : 因为 公有 类 是 包 的 API 的 一 部 分 ， 而 包 级 私有 的 顶层 类 则 已 经 是 这 个 包 的 
实现 的 一 部 分 。 


对 于 成 员 OR. DE, RASA EET) 有 四 种 可 能 的 访问 级 别 ， 下 面 按照 可 访问 性 的 
递增 顺序 罗列 出 来 : 


。 私 有 的 (private) 





只 有 在 声明 该 成 员 的 顶层 类 内 部 才 可 以 访问 这 个 成 员 。 


。 包 级 私有 的 (package-private) 一 -声明 该 成 员 的 包 内 部 的 任何 类 都 可 以 访问 这 个 成 
员 。 从 技术 上 讲 ， 它 被 称 为 “ 缺 省 (default) 访问 级 别 ”， 如 果 没 有 为 成 员 指定 访问 修 
饰 符 ， 就 采用 这 个 访问 级 别 。 


。 受 保护 的 (protected) 一 一 声明 该 成 员 的 类 的 子 类 可 以 访问 这 个 成 员 .( 但 有 一 些 限制 
[JLS, 6.6.2])， 并 且 ， 声 明 该 成 员 的 包 内 部 的 任何 类 也 可 以 访问 这 个 成 员 。 


。 公 有 的 (public) 一 一 在 任何 地 方 都 可 以 访问 该 成 员 。 


当 你 仔细 地 设计 了 类 的 公有 API 之 后 ， 可 能 觉得 应 该 把 所 有 其 他 的 成 员 都 变 成 私有 的 。 其 
实 ， 只 有 当 同 一 个 包 内 的 另 一 个 类 真正 需要 访问 一 个 成 员 的 时 候 ， 你 才 应 该 删除 private 修 饰 
符 ， 使 该 成 员 变 成 包 级 私有 的 。 如 果 你 发 现 自己 经 常 要 做 这 样 的 事情 ， 就 应 该 重新 检查 你 的 
系统 设计 ， 看 看 是 否 另 一 种 分 解 方案 所 得 到 的 类 ， 与 其 他 类 之 间 的 耦合 度 会 更 小 。 也 就 是 说 ， 
私有 成 员 和 包 级 私有 成 员 都 是 一 个 类 的 实现 中 的 一 部 分 ,一 般 不 会 影响 它 的 导出 的 API。 然 而 ， 
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如 果 这 个 类 实现 了 Serializable 接 口 ( 见 第 74 和 75 条 ) ， 这 些 域 就 有 可 能 会 被 “泄漏 (leak)” 
到 导出 的 API 中 。 


对 于 公有 类 的 成 员 ， 当 访问 级 别 从 包 级 私有 变 成 保护 级 别 时 ， 会 大 大 增强 可 访问 性 。 受 保 
护 的 成 员 是 类 的 导出 的 API 的 一 部 分 ， 必 须 永 远 得 到 支持 。 I aaa 
类 对 于 某 个 实现 细节 的 公开 承诺 ( 见 第 17 条 )。 受 保护 的 成 员 应 该 尽量 少 用 。 


有 一 条 规则 限制 了 降低 方法 的 可 访问 性 的 能 力 。 如 果 方 法 覆盖 了 超 类 中 的 一 个 方法 ， 子 类 
中 的 访问 级 别 就 不 允许 低 于 超 类 中 的 访问 级 别 [JLS, 8.4.8.3]。 这 样 可 以 确保 任何 可 使 用 超 类 的 
实例 的 地 方 也 都 可 以 使 用 子 类 的 实例 。 如 果 你 违反 了 这 条 规则 ， 那 么 当 你 试图 编译 该 子 类 的 
时 候 ， 编 译 器 就 会 产生 一 条 错误 消息 。 这 条 规则 有 种 特殊 的 情形 :如果 一 个 类 实现 了 一 个 接 
口 ， 那 么 接口 中 所 有 的 类 方法 在 这 个 类 中 也 都 必须 被 声明 为 公有 的 。 之 所 以 如 此 ， 是 因为 接 
口中 的 所 有 方法 都 隐 含 着 公有 访问 级 别 [JLS，9.1.5]。 


为 了 便于 测试 ， 你 可 以 试 着 使 类 、 接 口 或 者 成 员 变 得 更 容易 访问 。 这 么 做 在 一 定 程度 上 来 
说 是 好 的 。 为 了 测试 而 将 一 个 公有 类 的 私有 成 员 变 成 包 级 私有 的 ， 这 还 可 以 接受 ， 但 是 要 将 
访问 级 别提 高 到 超过 它 ， 这 就 无 法 接受 了 。 换 句 话说 ， 不 能 为 了 测试 ,而 将 类 、 接 口 或 者 成 
员 变 成 包 的 导出 的 API 的 一 部 分 。 幸 运 的 是 ， 也 没有 必要 这 么 做 ， 因 为 可 以 让 测试 作为 被 测试 
的 包 的 一 部 分 来 运行 ， 从 而 能 够 访问 它 的 包 级 私有 的 元 素 。 


实例 域 决 不 能 是 公有 的 ( 见 第 14 条 )。 如 果 域 是 非 final 的 , 或 者 是 一 个 指向 可 变 对 象 的 
final 引 用 ， 那 么 一 旦 使 这 个 域 成 为 公有 的 ， 就 放弃 了 对 存储 在 这 个 域 中 的 值 进行 限制 的 能 
力 ， 这 意味 着 ， 你 也 放弃 了 强制 这 个 域 不 可 变 的 能 力 。 同 时 ， 当 这 个 域 被 修改 的 时 候 ， 你 也 
失去 了 对 它 采 取 任 何 行动 的 能 力 。 因 此 ， 包 含 公有 可 变 域 的 类 并 不 是 线程 安全 的 。 即 使 域 是 
final 的 ， 并 且 引 用 不 可 变 的 对 象 ， 当 把 这 个 域 变 成 公有 的 时 候 ， 也 就 放弃 了 “切换 到 一 种 新 
的 内 部 数据 表示 法 ”的 灵活 性 。 


同样 的 建议 也 适用 于 静态 域 ， 只 是 有 一 种 例外 情况 。 假 设 常量 构成 了 类 提供 的 整个 抽象 中 
的 一 部 分 ， 可 以 通过 公有 的 静态 final 域 来 暴露 这 些 常量 。 按 惯例 ， 这 种 域 的 名 称 由 大 写字 母 
组 成 ,单词 之 间 用 下 划 线 隔 开 ( 见 第 56 条 )。 很 重要 的 一 点 是 ， 这 些 域 要 么 包含 基本 类 型 的 值 ， 
要 么 包含 指向 不 可 变 对 象 的 引用 ( 见 第 15 条 )。 如 果 final 域 包含 可 变 对 象 的 引用 ， 它 便 具有 非 
final 域 的 所 有 缺点 。 虽 然 引 用 本 身 不 能 被 修改 ， 但 是 它 所 引用 的 对 象 却 可 以 被 修改 一 一 这 会 导 
致 灾难 性 的 后 果 。 


狂 意 ， 长 度 非 零 的 数组 总 是 可 变 的 ， 所 以 ， 类 具有 公有 的 静态 final 数 组 域 ， 或 者 返回 这 种 
域 的 访问 方法 ， 这 几乎 总 是 错误 的 。 如 果 类 具有 这 样 的 域 或 者 访问 方法 ， 客 户 端 将 能 够 修改 
数组 中 的 内 容 。 这 是 安全 漏洞 的 一 个 常见 根源 : 
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// Potential security hole! 

public static final Thing[] VALUES = { ... }; 

要 注意 , 许多 IDE 会 产生 返回 指向 私有 数组 域 的 引用 的 访问 方法 , 这 样 就 会 产生 这 个 问题 。 
修正 这 个 问题 有 两 种 方法 。 可 以 使 公有 数组 变 成 私有 的 ， 并 增加 一 个 公有 的 不 可 变 列表 : 

private static final Thing[] PRIVATE_VALUES = { ... };. 


public static final List<Thing> VALUES = 
Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES)) ; 


另 一 种 方法 是 ， 可 以 使 数组 变 成 私有 的 ， 并 添加 一 个 公有 方法 ， 它 返回 私有 数组 的 一 个 
备份 : 
private static final Thing[] PRIVATE_VALUES = { ... }; 


public static final Thing[] values() { 
return PRIVATE_VALUES.clone(); 


要 在 这 两 种 方法 之 间 做 出 选择 ， 得 考虑 客户 端 可 能 怎么 处 理 这 个 结果 。 哪 种 返回 类 型 会 更 
加 方便 ? 哪 种 会 得 到 更 好 的 性 能 ? 


总 而 言 之 ， 你 应 该 始终 尽 可 能 地 降低 可 访问 性 。 你 在 仔细 地 设计 了 一 个 最 小 的 公有 API 
之 后 ， 应 该 防止 把 任何 散乱 的 类 、 接 口 和 成 员 变 成 API 的 一 部 分 。 除 了 公有 静态 final 域 的 特 
殊 情 形 之 外 ， 公 有 类 都 不 应 该 包含 公有 域 。 并 且 要 确保 公有 静态 final 域 所 引用 的 对 象 都 是 不 
可 变 的 。 


第 14 条 ， 在 公有 关中 使 用 访问 方法 而 





有 时 候 ， 可 能 会 编写 一 些 退化 类 (degenerate classes), 没有 什么 作用 ， 只 是 用 来 集中 实 
例 域 : 


// Degenerate classes like this should not be public! 
class Point { 

public double x; 

public double y; 


由 于 这 种 类 的 数据 域 是 可 以 被 直接 访问 的 ， 这 些 类 没有 提供 封装 (encapsulation) 的 功能 
( 见 第 13 条 )。 如 果 不 改变 API， 就 无 法 改变 它 的 数据 表示 法 ， 也 无 法 强加 任何 约束 条 件 ， 当 域 
被 访问 的 时 候 ， 无 法 采取 任何 辅助 的 行动 。 坚 持 面向 对 象 程序 设计 的 程序 员 对 这 种 类 深 恶 痛 
绝 ， 认 为 应 该 用 包含 私有 域 和 公有 访问 方法 (getter) 的 类 代替 。 对 于 可 变 的 类 来 说 ， 应 该 用 
包含 私有 域 和 公有 设 值 方法 (setter) 的 类 代替 : 
// Encapsulation of data by accessor methods and mutators 
class Point { 
private double x; 
private double y; 
public Point(double x, double y) { 


this.x = x; 
this.y = y; 


public double getX() { return x; } 
public double getY() { return y; } 
public void setX(double x) { this.x = x; } 


public void setY(double y) { this.y = y; } 
} 


毫 无 疑问 ， 说 到 公有 类 的 时 候 ， 坚 持 面 向 对 象 程 序 设计 思想 的 看 法 是 正确 的 : 如 果 类 可 以 
在 它 所 在 的 包 的 外 部 进行 访问 ， 就 提供 访问 方法 ， 以 保留 将 来 改变 该 类 的 内 部 表示 法 的 灵活 
性 。 如 果 公 有 类 暴露 了 它 的 数据 域 ， 要 想 在 将 来 改变 其 内 部 表示 法 是 不 可 能 的 ， 因 为 公有 类 
的 客户 端 代码 已 经 遍布 各 处 了 。 


然而 ， 如 果 类 是 包 级 私有 的 ， 或 者 是 私有 的 嵌 套 类 ， 直接 暴 露 它 的 数据 域 并 没有 本 质 的 错 
误 一 一 假设 这 些 数 据 域 确实 描述 了 该 类 所 提供 的 抽象 。 这 种 方法 比 访问 方法 的 做 法 更 不 会 产生 
视觉 混乱 ， 无 论 是 在 类 定义 中 ， 还 是 在 使 用 该 类 的 客户 端 代码 中 。 虽 然 客 户 端 代码 与 该 类 的 
内 部 表示 法 紧密 相连 ,但 是 这 些 代码 被 限定 在 包含 该 类 的 包 中 。 如 有 必要 ， 不 改变 包 之 外 的 
任何 代码 而 只 改变 内 部 数据 表示 法 也 是 可 以 的 。 在 私有 人 嵌 套 类 的 情况 下 ， 改 变 的 作用 范围 被 
进一步 限制 在 外 围 类 中 。 
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Java 平 台 类 库 中 有 几 个 类 违反 了 “公有 类 不 应 该 直接 暴露 数据 域 ” 的 告 诚 。 显 著 的 例子 包 
括 java.awt 包 中 的 Point 和 Dimension 类 。 它 们 是 不 值得 仿效 的 例子 ， 相 反 ， 这 些 类 应 该 被 当 作 
反面 的 警告 示例 。 正 如 第 55 条 中 所 讲述 的 ， 决 定 暴露 Dimension 类 的 内 部 数据 造成 了 严重 的 性 
能 问题 ， 而 且 ， 这 个 问题 至 今 依然 存在 。 


让 公有 类 直接 暴露 域 虽然 从 来 都 不 是 种 好 办 法 ， 但 是 如 果 域 是 不 可 变 的 ， 这 种 做 法 的 危害 
就 比较 小 一 些 。 如 果 不 改变 类 的 API， 就 无 法 改变 这 种 类 的 表示 法 ， 当 域 被 读 取 的 时 候 ， 你 也 
无 法 采取 辅助 的 行动 ， 但 是 可 以 强加 约束 条 件 。 例 如 ， 这 个 类 确保 了 每 个 实例 都 表示 一 个 有 
效 的 时 间 : 


// Public class with exposed immutable fields - questionable 
public final class Time { $ 

private static final int HOURS_PER_DAY = 24; 

private static final int MINUTES_PER_HOUR = 60; 


public final int hour; 
public final int minute; 


public Time(int hour, int minute) { 
if (hour < 0 || hour >= HOURS_PER_DAY) 
throw new IllegalArgumentException("Hour: " + hour); 
if (minute < 0 || minute >= MINUTES_PER_HOUR) 
throw new IllegalArgumentException("Min: " + minute); 
this.hour = hour; 
this.minute = minute; 


.. // Remainder omitted 
} . 


总 之 ， 公 有 类 永远 都 不 应 该 暴露 可 变 的 域 。 虽 然 还 是 有 问题 ， 但 是 让 公有 类 暴露 不 可 变 的 
域 其 危害 比较 小 。 但 是 ， 有 时 候 会 需要 用 包 级 私有 的 或 者 私有 的 嵌 套 类 来 暴露 域 ， 无 论 这 个 
类 是 可 变 还 是 不 可 变 的 。 
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不 可 变 类 只 是 其 实例 不 能 被 修改 的 类 。 每 个 实例 中 包含 的 所 有 信息 都 必须 在 创建 该 实例 的 
时 候 就 提供 ， 并 在 对 象 的 整个 生命 周期 (lifetime) 内 固定 不 变 。Java 平 台 类 库 中 包含 许多 不 
可 变 的 类 ， 其 中 有 String、 基 本 类 型 的 包装 类 、BigInteger 和 BigDecimal。 存 在 不 可 变 的 类 有 
许多 理由 : 不 可 变 的 类 比 可 变 类 更 加 易于 设计 、 实 现 和 使 用 。 它们 不 容易 出 错 ， 且 更 加 安全 。 


为 了 使 类 成 为 不 可 变 ， 要 遵循 下 面 五 条 规则 ; 
1. 不 要 提供 任何 会 修改 对 象 状态 的 方法 (也 称 为 mutator) © 


2. 保证 类 不 会 被 扩展 。 这 样 可 以 防止 粗心 或 者 恶意 的 子 类 假装 对 象 的 状态 已 经 改变 ， 从 
而 破坏 该 类 的 不 可 变 行 为 。 为 了 防止 子 类 化 ， 一 般 做 法 是 使 这 个 类 成 为 final 的 ， 但 是 后 面 我 
们 还 会 讨论 到 其 他 的 做 法 。 


3. 使 所 有 的 域 都 是 final 的 。 通 过 系统 的 强制 方式 ， 这 可 以 清楚 地 表明 你 的 意图 。 而 且 ， 
如 果 一 个 指向 新 创建 实例 的 引用 在 缺乏 同步 机 制 的 情况 下 ， 从 一 个 线程 被 传递 到 另 一 个 线程 ， 
就 必需 确保 正确 的 行为 ， 正 如 内 存 模 型 (memory model) 中 所 述 [JLS，17.5，Goetz06 16], 


4. 使 所 有 的 域 都 成 为 私有 的 。 这 样 可 以 防止 客户 端 获 得 访问 被 域 引用 的 可 变 对 象 的 权限 ， 
并 防止 客户 端 直接 修改 这 些 对 象 。 虽 然 从 技术 上 讲 ， 人 允许 不 可 变 的 类 具有 公有 的 final 域 ， 只 
要 这 些 域 包含 基本 类 型 的 值 或 者 指向 不 可 变 对 象 的 引用 ,但 是 不 建议 这 样 做 ， 因 为 这 样 会 使 
得 在 以 后 的 版 本 中 无 法 再 改变 内 部 的 表示 法 ( 见 第 13 条 )。 


5. 确保 对 于 任何 可 变 组 件 的 互 斥 访问 。 如 果 类 具有 指向 可 变 对 象 的 域 ， 则 必须 确保 该 类 
的 客户 端 无 法 获得 指向 这 些 对 象 的 引用 。 并 且 ， 永 远 不 要 用 客户 端 提供 的 对 象 引 用 来 初始 化 
这 样 的 域 ， 也 不 要 从 任何 访问 方法 (accessor) 中 返回 该 对 象 引 用 。 在 构造 器 、 访 问 方法 和 
readObject 方 法 ( 见 第 76 条 ) 中 请 使 用 保护 性 找 贝 (defensive copy) 技术 ( 见 第 39 条 )。 


前 面条 目 中 的 许多 例子 都 是 不 可 变 的 ， 其 中 一 个 例子 是 第 9 条 中 的 PhoneNumber， 它 针对 
每 个 属性 都 有 访问 方法 (accessor)， 但 是 没有 对 应 的 设 值 方法 (mutator) 。 下 面 是 个 稍微 复 
杂 一 点 的 例子 : 

public final class Complex { 

private final double re; 


private final double im; 


public Complex(double re, double im) { 


O 即 改变 对 象 属 性 的 方法 。 一 一 编辑 注 。 
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this.re = re; . 
this.im = im; 

} 

// Accessors with no corresponding mutators 

public double realPart() { return re; } 


public double imaginaryPart() { return im; } 


public Complex add(Complex c) { 
return new Complex(re + c.re, im + c.im); 


public Complex subtract(Complex c) { 
return new Complex(re - c.re, im - c.im); 
} 


public Complex multiply(Complex c) { 
return new Complex(re * c.re - im * c.im, 
re +» c.im + im * c.re); 


} 


public Complex divide(Complex c) { 
double tmp = c.re + c.re + Clim + c.im; 
return new Complex((re * c.re + im * c.im) / tmp, 
Cim * c.re - re * c.im) / tmp); 


} 


@Override public boolean equals(Object o) { 
if (o == this) 
return true; 
if (!(o instanceof Complex)) 
return false; 
Complex c = (Complex) o; 


// See page 43 to find out why we use compare instead of == 


return Double.compare(re, c.re) == 0 & 
Double.compare(im, c.im) == 0; 
} 


@Override public int hashCode()- { 
int result = 17 + hashDouble(re); 
result = 31 * result + hashDouble(im); 
return result; 

} 

private int hashDouble(double val) { 
long longBits = Double.doubleToLongBits(re) ; 
return (int) ClongBits A (longBits >>> 32)); 


@Override public String toString() { 
return "(" + re + "+" + im+ "i)"; 


这 个 类 表示 一 个 复数 (complex number， 具 有 实 部 和 虚 部 ) 。 除 了 标准 的 Object 方法 之 外 ， 
它 还 提供 了 针对 实 部 和 虚 部 的 访问 方法 ， 以 及 4 种 基本 的 算术 运算 : 加 法、 减法 、 乘 法 和 除法 。 
注意 这 些 算 术 运 算是 如 何 创 建 并 返回 新 的 Complex 实 例 ， 而 不 是 修改 这 个 实例 。 大 多 数 重要 的 
不 可 变 类 都 使 用 了 这 种 模式 。 它 被 称 为 函数 的 (funetional) 做 法 ， 因 为 这 些 方法 返回 了 一 个 
函数 的 结果 ， 这 些 函 数 对 操作 数 进行 运算 但 并 不 修改 它 。 与 之 相对 应 的 更 常见 的 是 过 程 的 
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(procedural) 或 者 命令 式 的 (imperative) 做 法 ， 使 用 这 些 方 式 时 ， 将 一 个 过 程 作 用 在 它们 
的 操作 数 上 ， 会 导致 它 的 状态 发 生 改变 。 


如 果 你 对 函数 方式 的 做 法 还 不 太 熟 悉 ， 可 能 会 觉得 它 显得 不 太 自然 ， 但 是 它 带 来 了 不 可 变 
性 ， 具 有 许多 优点 。 不 可 变 对 象 比较 简单 。 不 可 变 对 象 可 以 只 有 一 种 状态 ， 即 被 创建 时 的 状 
态 。 如 果 你 能 够 确保 所 有 的 构造 器 都 建立 了 这 个 类 的 约束 关系 ， 就 可 以 确保 这 些 约束 关系 在 
整个 生命 周期 内 永远 不 再 发 生变 化 ， 你 和 使 用 这 个 类 的 程序 员 都 无 需 再 做 额外 的 工作 来 维护 
这 些 约束 关系 。 男 一 方面 ， 可 变 的 对 象 可 以 有 任意 复杂 的 状态 空间 。 如 果 文 档 中 没有 对 
mutator 方 法 所 执行 的 状态 转换 提供 精确 的 描述 ， 要 可 靠 地 使 用 一 个 可 变 类 是 非常 困难 的 ， 其 
至 是 不 可 能 的 。 


不 可 变 对 象 本 质 上 是 线程 安全 的 ， 它 们 不 要 求 同 步 。 当 多 个 线程 并 发 访问 这 样 的 对 象 时 ， 
它们 不 会 遭 到 破坏 。 这 无 疑 是 获得 线程 安全 最 容易 的 办 法 。 实 际 上 ， 没 有 任何 线程 会 注意 到 
其 他 线程 对 于 不 可 变 对 象 的 影响 。 所 以 ， 不 可 变 对 象 可 以 被 自由 地 共享 。 不 可 变 类 应 该 充分 
利用 这 种 优势 ， 鼓 励 客户 端 尽 可 能 地 重用 现 有 的 实例 。 要 做 到 这 一 点 ， 一 个 很 简便 的 办 法 就 
是 ， 对 于 频繁 用 到 的 值 ， 为 它们 提供 公有 的 静态 final 常 量 。 例 如 ，Complex 类 有 可 能 会 提供 下 
面 的 常量 : 

public static final Complex ZERO = new Complex(@, 0); 


public static final Complex ONE = new Complex(1, 0); 
public static final Complex I = new Complex(@, 1); 


这 种 方法 可 以 被 进一步 扩展 。 不 可 变 的 类 可 以 提供 一 些 静态 工厂 ( 见 第 1 条 )， 它 们 把 频 
繁 被 请 求 的 实例 缓存 起 来 ， 从 而 当 现 有 实例 可 以 符合 请 求 的 时 候 ， 就 不 必 创 建新 的 实例 。 所 
有 基本 类 型 的 包装 类 和 BigInteger 都 有 这 样 的 静态 工厂 。 使 用 这 样 的 静态 工厂 也 使 得 客户 端 之 
间 可 以 共享 现 有 的 实例 ， 而 不 用 创建 新 的 实例 ， 从 而 降低 内 存 占用 和 垃圾 回收 的 成 本 。 在 设 
计 新 的 类 时 ， 选 择 用 静态 工厂 代替 公有 的 构造 器 可 以 让 你 以 后 有 添加 缓存 的 灵活 性 ， 而 不 必 
影响 客户 端 。 


“不 可 变 对 象 可 以 被 自由 地 共享 ”导致 的 结果 是 ， 永 远 也 不 需要 进行 保护 性 拷贝 ( 见 第 39 
条 )。 实 际 上 ， 你 根本 无 需 做 任何 拷贝 ， 因 为 这 些 拷贝 始终 等 于 原始 的 对 象 。 因 此 ， 你 不 需要 ， 
也 不 应 该 为 不 可 变 的 类 提供 clone 方 法 或 者 描 贝 构造 器 (copy constructor， 见 第 11 条 )。 这 一 
点 在 Java 平 台 的 早期 并 不 好 理解 ， 所 以 String 类 仍然 具有 拷贝 构造 器 ， 但 是 应 该 尽量 少 用 它 
( 见 第 5 条 ) 。 


不 仅 可 以 共享 不 可 变 对 象 ， 甚 至 也 可 以 共享 它们 的 内 部 信息 。 例 如 ，BigInteger 类 内 部 使 
用 了 符号 数值 表示 法 。 符 号 用 一 个 int 类 型 的 值 来 表示 ， 数 值 则 用 一 个 int 数 组 表示 。negate 方 
法 产生 一 个 新 的 BigInteger， 其 中 数值 是 一 样 的， 符号 则 是 相反 的 。 它 并 不 需要 拷贝 数组 ， 新 
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建 的 BigInteger 也 指向 原始 实例 中 的 同一 个 内 部 数组 。 


不 可 变 对 象 为 其 他 对 象 提 供 了 大 量 的 构件 (building blocks) ， 无 论 是 可 变 的 还 是 不 可 变 
的 对 象 。 如 果 知 道 一 个 复杂 对 象 内 部 的 组 件 对 象 不 会 改变 ， 要 维护 它 的 不 变性 约束 是 比较 容 
易 的 。 这 条 原则 的 一 种 特例 在 于 ， 不 可 变 对 象 构成 了 大 量 的 映射 键 (map key) 和 集合 元 素 
(set element) ;一旦 不 可 变 对 象 进 入 到 映射 (map) 或 者 集合 (set) 中 ,尽管 这 破坏 了 映射 
或 者 集合 的 不 变性 约束 ， 但 是 也 不 用 担心 它们 的 值 会 发 生变 化 。 


不 可 变 类 真正 唯一 的 缺点 是 ， 对 于 每 个 不 同 的 值 都 需要 一 个 单独 的 对 象 。 创 建 这 种 对 象 的 
代价 可 能 很 高 ， 特 别 是 对 于 大 型 对 象 的 情形 。 例 如 ， 假 设 你 有 一 个 上 百 万 位 的 BigInteger， 想 
要 改变 它 的 低位 : 


BigInteger moby = ...; 
moby = moby.flipBit(@); 


flipBit 方 法 创建 了 一 个 新 的 BigInteger 实 例 ， 也 有 上 百 万 位 长 ， 它 与 原来 的 对 象 只 差 一 位 
不 同 。 这 项 操作 所 消耗 的 时 间 和 空间 与 BigInteger 的 成 正比 。 我 们 拿 它 与 java.util.BitSet 进 行 
比较 。 与 BigInteger 类 似 ，BitSet 代 表 一 个 任意 长 度 的 位 序列 ， 但 是 与 BigInteger 不 同 的 是 ， 
BitSet 是 可 变 的 。BitSet 类 提供 了 一 个 方法 ， 人 允许 在 固定 时 间 (constant time) 内 改变 此 “ 百 
万 位 ”实例 中 单个 位 的 状态 。 


如 果 你 执行 一 个 多 步骤 的 操作 ， 并 且 每 个 步骤 都 会 产生 一 个 新 的 对 象 ， 除 了 最 后 的 结果 之 
外 其 他 的 对 象 最 终 都 会 被 丢弃 ， 此 时 性 能 问题 就 会 显露 出 来 。 处 理 这 种 问题 有 两 种 办 法 。 第 
一 种 办 法 ， 先 猜测 一 下 会 经 常用 到 哪些 多 步骤 的 操作 ， 然 后 将 它们 作为 基本 类 型 提供 。 如 果 
某 个 多 步 又 操作 已 经 作为 基本 类 型 提供 ， 不 可 变 的 类 就 可 以 不 必 在 每 个 步骤 单独 创建 一 个 对 
象 。 不 可 变 的 类 在 内 部 可 以 更 加 灵活 。 例 如 ，BigInteger 有 一 个 包 级 私有 的 可 变 “ 配 套 类 
(companing class)”， 它 的 用 途 是 加 速 诸如 “ 模 指 数 (modular exponentiation)” 这 样 的 多 步 
又 操作 。 由 于 前 面 提 到 的 诸多 原因 ， 使 用 可 变 的 配套 类 比 使 用 BigInteger 要 困难 得 多 ， 但 幸运 
的 是 ， 你 并 不 需要 这 样 做 。 因 为 BigInteger 的 实现 者 已 经 替 你 完成 了 所 有 的 困难 工作 。 


如 果 能 够 精确 地 预测 出 客户 端 将 要 在 不 可 变 的 类 上 执行 哪些 复杂 的 多 阶段 操作 ， 这 种 包 级 
私有 的 可 变 配套 类 的 方法 就 可 以 工作 得 很 好 。 如 果 无 法 预测 ， 最 好 的 办 法 是 提供 一 个 公有 的 
可 变 配套 类 。 在 Java 平 台 类 库 中 ， 这 种 方法 的 主要 例子 是 String 类 ， 它 的 可 变 配 套 类 是 
StringBuilder (和 基本 上 已 经 废弃 的 StringBuffer)。 可 以 这 样 认为 ， 在 特定 的 环境 下 ， 相 对 于 
BigInteger 而 言 ，BitSet 同 样 扮演 了 可 变 配套 类 的 角色 。 


现在 你 已 经 知道 了 如 何 构建 不 可 变 的 类 ， 并 且 了 解 了 不 可 变性 的 优点 和 缺点 ， 现 在 我 们 来 
讨论 其 他 的 一 些 设计 方案 。 前 面 提 到 过 ， 为 了 确保 不 可 变性 ， 类 绝对 不 允许 自身 被 子 类 化 。 
除了 “使 类 成 为 final 的 ”这 种 方法 之 外 ， 还 有 另外 一 种 更 加 灵活 的 办 法 可 以 做 到 这 一 点 。 让 
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不 可 变 的 类 变 成 final 的 另 一 种 办 法 就 是 ， 让 类 的 所 有 构造 器 都 变 成 私有 的 或 者 包 级 私有 的 ， 
并 添加 公有 的 静态 工厂 (static factory) 来 代替 公有 的 构造 器 (LIA). 


为 了 具体 说 明 这 种 方法 ， 下 面 以 Complex 为 例 ， 看 看 如 何 使 用 这 种 方法 : 


// Immutable class with static factories instead of constructors 
public class Complex { 
private final double re; 
private final double im; 
private Complex(double re, double im) { 
this.re = re; 
this.im = im; 
} 
public static Complex valueOf(double re, double im) { 
return new Complex(re, im); 
} 


... // Remainder unchanged 


虽然 这 种 方法 并 不 常用 ， 但 它 经 常 是 最 好 的 替代 方法 。 它 最 灵活 ， 因 为 它 允 许 使 用 多 个 包 
级 私有 的 实现 类 。 对 于 处 在 它 的 包 外 部 的 客户 端 而 言 ， 不 可 变 的 类 实际 上 是 final 的 ， 因 为 不 
可 能 把 来 自 另 一 个 包 的 类 、 缺 少 公有 的 或 受 保护 的 构造 器 的 类 进行 扩展 。 除 了 允许 多 个 实现 
类 的 灵活 性 之 外 ， 这 种 方法 还 使 得 有 可 能 通过 改善 静态 工厂 的 对 象 缓存 能 力 ， 在 后 续 的 发 行 
版 本 中 改进 该 类 的 性 能 。 


静态 工厂 与 构造 器 相 比 具有 许多 其 他 的 优势 ， 正 如 在 第 1 条 中 所 讨论 的 。 例 如 ， 假 设 你 希 
望 提 供 一 种 “基于 极 坐 标 创 建 复 数 ” 的 方式 。 如 果 使 用 构造 器 来 实现 这 样 的 功能 ， 可 能 会 使 
得 这 个 类 很 零乱 ， 因 为 这 样 的 构造 器 与 已 用 的 构造 器 Complex(double, double) 具 有 相同 的 签 
名 。 通 过 静态 工厂 ， 这 很 容易 做 到 。 只 需 添加 第 二 个 静态 工 三， 并 且 工 厂 的 名 字 清 楚 地 表明 
了 它 的 功能 即 可 : 

public static Complex valueOfPolar(double r, double theta) { 


return new Complex(r * Math.cos(theta), 
r * Math.sin(theta)); 
} ’ 


当 BigInteger 和 BigDecimal 刚 被 编写 出 来 的 时 候 ， 对 于 “不 可 变 的 类 必须 为 final 的 ”还 没 
有 得 到 广泛 地 理解 ， 所 以 它们 的 所 有 方法 都 有 可 能 会 被 覆盖 。 遗 憾 的 是 ， 为 了 保持 向 后 兼容 ， 
这 个 问题 一 直 无 法 得 以 修正 。 如 果 你 在 编写 一 个 类 ， 它 的 安全 性 依赖 于 (来 自 不 可 信 客 户 端 
的 ) BigInteger 或 者 BigDecimal 参 数 的 不 可 变性 ， 就 必须 进行 检查 ， 以 确定 这 个 参数 是 否 为 
“真正 的 ”的 BigInteger 或 者 BigDecimal， 而 不 是 不 可 信任 子 类 的 实例 。 如 果 是 后 者 的 话 ， 就 
必须 在 假设 它 可 能 是 可 变 的 前 提 下 对 它 进行 保护 性 拷贝 ( 见 第 39 条 ) : 


public static BigInteger safeInstance(BigInteger val) { 
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if (val.getClass() != BigInteger.class) 
return new BigInteger(val.toByteArray()); 
return val; 


本 条 目 开头 处 关于 不 可 变 类 的 诸多 规则 指出 ， 没 有 方法 会 修改 对 象 ， 并 且 它 的 所 有 域 都 必 
须 是 final 的 。 实 际 上 ， 这 些 规则 比 真正 的 要 求 更 强硬 了 一 点 ， 为 了 提高 性 能 可 以 有 所 放松 。 
事实 上 应 该 是 这 样 : 没有 一 个 方法 能 够 对 对 象 的 状态 产生 外 部 可 见 (externally visible) 的 改 
变 。 然 而 ， 许 多 不 可 变 的 类 拥有 一 个 或 者 多 个 非 final 的 域 ， 它 们 在 第 一 次 被 请 求 执行 这 些 计 
算 的 时 候 ， 把 一 些 开销 昂贵 的 计算 结果 缓存 在 这 些 域 中 。 如 果 将 来 再 次 请 求 同 样 的 计算 ， 就 
直接 返回 这 些 缓存 的 值 ， 从 而 节约 了 重新 计算 所 需要 的 开销 。 这 种 技巧 可 以 很 好 地 工作 ， 因 
为 对 象 是 不 可 变 的 ， 它 的 不 可 变性 保证 了 这 些 计算 如 果 被 再 次 执行 ， 就 会 产生 同样 的 结果 。 


例如 ，PhoneNumber 类 的 hashCode 方 法 ( 见 第 9 条 ) 在 第 一 次 被 调用 的 时 候 ， 计 算出 散 列 
码 ， 然 后 把 它 缓存 起 来 ， 以 备 将 来 被 再 次 调用 时 使 用 。 这 种 方法 是 延迟 初始 化 (lazy 
initialization) ( 见 第 71 条 ) 的 一 个 例子 ， String 类 也 用 到 了 。 


有 关 序 列 化 功能 的 一 条 告诫 有 必要 在 这 里 提出 来 。 如 果 你 选择 让 自己 的 不 可 变 类 实现 
Serializable 接 口 ， 并 且 它 包含 一 个 或 者 多 个 指向 可 变 对 象 的 域 ， 就 必须 提供 一 个 显 式 的 
readObject 或 者 readResolve 方 法 ， 或 者 使 用 ObjectOutputStream.writeUnshared 和 
ObjectInputStream.readUnshared 方 法 ， 即 使 默认 的 序列 化 形式 是 可 以 接受 的 ， 也 是 如 此 。 否 
则 攻击 者 可 能 从 不 可 变 的 类 创建 可 变 的 实例 。 这 个 话题 的 详细 内 容 请 参见 第 76 条 。 


总 之 ， 坚 决 不 要 为 每 个 get 方 法 编写 一 个 相应 的 set 方 法 。 除 非 有 很 好 的 理由 要 让 类 成 为 可 
变 的 类 ， 否 则 惑 应 该 是 不 可 变 的 。 不 可 变 的 类 有 许多 优点 ， 唯 一 缺点 是 在 特定 的 情况 下 存在 
潜在 的 性 能 问题 。 你 应 该 总 是 使 一 些小 的 值 对 象 ， 比 如 PhoneNumber 和 Complex， 成 为 不 可 变 
的 (在 Java 平 台 类 库 中 ， 有 几 个 类 如 java.util.Date 和 java.awt.Point， 它 们 本 应 该 是 不 可 变 的 ， 
但 实际 上 却 不 是 )。 你 也 应 该 认真 考虑 把 一 些 较 大 的 值 对 象 做 成 不 可 变 的 ， 例 如 String 和 
BigInteger。 只 有 当 你 确认 有 必要 实现 令 人 满意 的 性 能 时 ( 见 第 55 条 ) ， 才 应 该 为 不 可 变 的 类 

提供 公有 的 可 变 配套 类 。 


对 于 有 些 类 而 言 ， 其 不 可 变性 是 不 切实 际 的 。 如 果 类 不 能 被 做 成 是 不 可 变 的 ， 仍 然 应 该 尽 
可 能 地 限制 它 的 可 变性 。 降 低 对 象 可 以 存在 的 状态 数 ， 可 以 更 容易 地 分 析 该 对 象 的 行为 ， 同 
时 降低 出 错 的 可 能 性 。 因 此 ， 除 非 有 令 人 信服 的 理由 要 使 域 变 成 是 非 final 的 ， 否 则 要 使 每 个 
域 都 是 final 的 。 


构造 器 应 该 创建 完全 初始 化 的 对 象 ， 并 建立 起 所 有 的 约束 关系 。 不 要 在 构造 器 或 者 静态 工 
三 之 外 再 提供 公有 的 初始 化 方法 ， 除 非 有 令 人 信服 的 理由 必须 这 么 做 。 同 样 地 ， 也 不 应 该 提 
供 “ 重 新 初始 化 ”方法 ( 它 使 得 对 象 可 以 被 重用 ， 就 好 像 这 个 对 象 是 由 另 一 不 同 的 初始 状态 
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构造 出 来 的 一 样 ) 。 与 所 增加 的 复杂 性 相 比 ,“ 重 新 初始 化 ”方法 通常 并 没有 带 来 太 多 的 性 能 
优势 。 

可 以 通过 TimerTask 类 来 说 明 这 些 原则 。 它 是 可 变 的 ， 但 是 它 的 状态 空间 被 有 意 地 设计 得 
非常 小 。 你 可 以 创建 一 个 实例 ， 对 它 进行 调度 使 它 执 行 起 来 ， 也 可 以 随意 地 取消 它 。 一 旦 一 
个 定时 器 任务 (timer task) 已 经 完成 ， 或 者 已 经 被 取消 ， 就 不 可 能 再 对 它 重 新 调度 。 


最 后 值得 注意 的 一 点 与 本 条 目 中 的 Complex 类 有 关 。 这 个 例子 只 是 被 用 来 演示 不 可 变性 的 ， 
它 不 是 一 个 工业 强度 ( 即 产 品级 ) 的 复数 实现 。 它 对 复数 乘法 和 除法 使 用 标准 的 计算 公式 ， 
会 进行 不 正确 的 伟人 ， 并 对 复数 NaN 和 无 穷 大 没有 提供 很 好 的 语义 [Kahan91， Smith62, 
Thomas94], 
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第 16 条 : 复合 优先 于 继承 





继承 (inheritance) 是 实现 代码 重用 的 有 力 手段 ， 但 它 并 非 永远 是 完成 这 项 工作 的 最 佳 工 
具 。 使 用 不 当 会 导致 软件 变 得 很 脆弱 。 在 包 的 内 部 使 用 继承 是 非常 安全 的 ， 在 那里 ， 子 类 和 
超 类 的 实现 都 处 在 同一 个 程序 员 的 控制 之 下 。 对 于 专门 为 了 继承 而 设计 、 并 且 具 有 很 好 的 文 
档 说 明 的 类 来 说 ( 见 第 17 条 )， 使 用 继承 也 是 非常 安全 的 。 然 而 ， 对 普通 的 具体 类 (concrete 
class) 进行 跨越 包 边界 的 继承 ， 则 是 非常 危险 的 。 提 示 一 下 ， 本 书 使 用 “继承 ”一 词 ， 含义 
是 实现 继承 (implementation inheritance， 当 一 个 类 扩展 另 一 个 类 的 时 候 ) 。 本 条 目 中 讨论 
的 问题 并 不 适用 于 接口 继承 (interface inheritance， 当 一 个 类 实现 一 个 接口 的 时 候 ， 或 者 当 
一 个 接口 扩展 另 一 个 接口 的 时 候 ) 。 


与 方法 调用 不 同 的 是 ， 继 承 打 破 了 封装 性 [Snyder86]。 换 句 话说 ， 子 类 依赖 于 其 超 类 中 特 
定 功 能 的 实现 细节 。 超 类 的 实现 有 可 能 会 随 着 发 行 版 本 的 不 同 而 有 所 变化 ， 如 果真 的 发 生 了 
变化 ， 子 类 可 能 会 遭 到 破坏 ， 即 使 它 的 代码 完全 没有 改变 。 因 而 ， 子 类 必须 要 跟着 其 超 类 的 
更 新 而 演变 ， 除 非 超 类 是 专门 为 了 扩展 而 设计 的 ， 并 且 具 有 很 好 的 文档 说 明 。 


为 了 说 明 得 更 加 具体 一 点 ， 我 们 假设 有 一 个 程序 使 用 了 HashSet。 为 了 调 优 该 程序 的 性 能 ， 
需要 查询 HashSet， 看 一 看 自从 它 被 创建 以 来 曾经 添加 了 多 少 个 元 素 (不 要 与 它 当 前 的 元 素 混 
消 起 来 ， 元 素数 目 会 随 着 元 素 的 删除 而 递减 ) 。 为 了 提供 这 种 功能 ， 我 们 得 编写 一 个 HashSet 
变量 ， 它 记录 下 试图 插入 的 元 素数 量 ， 并 针对 该 计数 值 导出 一 个 访问 方法 。HashSet 类 包含 两 
个 可 以 增加 元 素 的 方法 : add 和 addAll， 因 此 这 两 个 方法 都 要 被 覆盖 : 


// Broken - Inappropriate use of inheritance! 

public class InstrumentedHashSet<E> extends HashSet<E> { 
// The number of attempted element insertions 
private int addCount = 0; 


public InstrumentedHashSet() { 
} 


public InstrumentedHashSet(int initCap, float loadFactor) { 
super(initCap, loadFactor); 


@Override public boolean add(E e) { 
addCount++; 
return super.add(e); 
} 
@Override public boolean addAl1(Collection<? extends E> ao f{ 
addCount += c.size(); 
return super.addAll(c); 


public int getAddCount() { 
return addCount; 
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这 个 类 看 起 来 非常 合理 ， 但 是 它 并 不 能 正常 工作 。 假 设 我 们 创建 了 一 个 实例 ， 并 利用 
addAll 方 法 添加 了 三 个 元 素 : 
InstrumentedHashSet<String> s = 


new InstrumentedHashSet<String>(); 
s.addAll(Arrays.asList("Snap", "Crackle", "Pop")); 


这 时 候 ， 我 们 期 望 getAddCount 方 法 将 会 返回 3， 但 是 它 实 际 上 返回 的 是 6。 哪 里 出 错 了 
WE? 在 HashSet 的 内 部 ，addAll 方 法 是 基于 它 的 add 方 法 来 实现 的 ， 即 使 HashSet 的 文档 中 并 没 
有 说 明 这 样 的 实现 细节 ， 这 也 是 合理 的 。InstrumentedHashSet 中 的 addAll 方 法 首先 给 
addCount 增 加 3， 然 后 利用 supper.addAll 来 调用 HashSet 的 addAll 实 现 。 然 后 又 依次 调用 到 被 
InstrumentedHashSet 和 覆盖 了 的 add 方 法 ， 每 个 元 素 调用 一 次 。 这 三 次 调用 又 分 别 给 addCount 加 
T1, WA, 总共 增 加 了 6: 通过 addAll 方 法 增加 的 每 个 元 素 都 被 计算 了 两 次 。 


我 们 只 要 去 掉 被 覆盖 的 addAll 方 法 ， 就 可 以 “修正 ”这 个 子 类 。 虽 然 这 样 得 到 的 类 可 以 正 
常 工 作 ， 但 是 ， 它 的 功能 正确 性 则 需要 依赖 于 这 样 的 事实 : HashSet 的 addAll 方 法 是 在 它 的 
add 方 法 上 实现 的 。 这 种 “自用 性 (self-use)” 是 实现 细节 ， 不 是 承诺 ， 不 能 保证 在 Java 平 台 
的 所 有 实现 中 都 保持 不 变 ， 不 能 保证 随 着 发 行 版 本 的 不 同 而 不 发 生变 化 。 因 此 ， 这 样 得 到 的 
InstrumentedHashSet 类 将 是 非常 脆弱 的 。 


稍微 好 一 点 的 做 法 是 ， 覆 盖 addAll 方 法 来 遍历 指定 的 集合 ， 为 每 个 元 素 调用 一 次 add 方 法 。 
这 样 做 可 以 保证 得 到 正确 的 结果 ， 不 管 HashSet 的 addAll 方 法 是 否 是 在 add 方 法 的 基础 上 实现 ， 
因为 HashSet 的 addAl 实 现 将 不 会 再 被 调用 到 。 然 而 ， 这 项 技术 并 没有 解决 所 有 的 问题 ， 它 相 
当 于 重新 实现 了 超 类 的 方法 ， 这 些 超 类 的 方法 可 能 是 自用 的 (self-use) ， 也 可 能 不 是 自用 的 ， 
这 种 方法 很 困难 ， 也 非常 耗 时 ， 并 且 容 易 出 错 。 此 外 ， 这 样 做 并 不 总 是 可 行 的 ， 因 为 无 法 访 
问 对 于 子 类 来 说 的 私有 域 ， 所 以 有 些 方 法 就 无 法 实现 。 


导致 子 类 脆弱 的 一 个 相关 的 原因 是 ， 它 们 的 超 类 在 后 续 的 发 行 版 本 中 可 以 获得 新 的 方法 。 
假设 一 个 程序 的 安全 性 依赖 于 这 样 的 事实 : 所 有 被 插入 到 某 个 集合 中 的 元 素 都 满足 某 个 先决 
条 件 。 下 面 的 做 法 就 可 以 确保 这 一 点 : 对 集合 进行 子 类 化 ， 并 覆盖 所 有 能 够 添加 元 素 的 方法 ， 
以 便 确 保 在 加 入 每 个 元 素 之 前 它 是 满足 这 个 先决 条 件 的。 如 果 在 后 续 的 发 行 版 本 中 ， 超 类 中 
没有 增加 能 插入 元 素 的 新 方法 ， 这 种 做 法 就 可 以 正常 工作 。 然 而 ,一旦 超 类 增加 了 这 样 的 新 方 
法 ， 则 很 可 能 仅仅 由 于 调用 了 这 个 未 被 子 类 覆盖 的 新 方法 ， 而 将 “非法 的 ”元 素 添加 到 子 类 的 
实例 中 。 这 不 是 个 纯粹 的 理论 问题 。 在 把 Hashtable 和 Vector 加 入 到 Collections Framework +1 fy 
时 候 ， 就 修正 了 几 个 这 类 性 质 的 安全 漏洞 。 


上 面 这 两 个 问题 都 来 源 于 覆盖 (overriding) 动作 。 如 果 在 扩展 一 个 类 的 时 候 ， 仅 仅 是 增 
加 新 的 方法 ， 而 不 覆盖 现 有 的 方法 ， 你 可 能 会 认为 这 是 安全 的 。 虽 然 这 种 扩展 方式 比较 安全 
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一 些 ， 但 是 也 并 非 完 全 没有 风险 。 如 果 超 类 在 后 续 的 发 行 版 本 中 获得 了 一 个 新 的 方法 ， 并 且 
不 幸 的 是 ， 你 给 子 类 提供 了 一 个 签名 相同 但 返回 类 型 不 同 的 方法 ， 那 么 这 样 的 子 类 将 无 法 通 
过 编译 [JLS, 8.4.6.3]。 如 果 给 子 类 提供 的 方法 带 有 与 新 的 超 类 方法 完全 相同 的 签名 和 返回 类 
型 ， 实 际 上 就 覆盖 了 超 类 中 的 方法 ， 因 此 又 回 到 上 述 的 两 个 问题 上 去 了 。 此 外 ， 你 的 方法 是 
否 能 够 遵守 新 的 超 类 方法 的 约定 ， 这 也 是 很 值得 怀疑 的 ， 因 为 当 你 在 编写 子 类 方法 的 时 候 ， 
这 个 约定 根本 没有 面世 。 


幸运 的 是 ， 有 一 种 办 法 可 以 避免 前 面 提 到 的 所 有 问题 。 不 用 扩展 现 有 的 类 ， 而 是 在 新 的 类 
中 增加 一 个 私有 域 ， 它 引用 现 有 类 的 一 个 实例 。 这 种 设计 被 称 做 “复合 (composition)”， 因 
为 现 有 的 类 变 成 了 新 类 的 一 个 组 件 。 新 类 中 的 每 个 实例 方法 都 可 以 调用 被 包含 的 现 有 类 实例 
中 对 应 的 方法 ， 并 返回 它 的 结果 。 这 被 称 为 转发 forwarding) ， 新 类 中 的 方法 被 称 为 转发 方 
法 (forwarding method)。 这 样 得 到 的 类 将 会 非常 稳固 ， 它 不 依赖 于 现 有 类 的 实现 细节 。 即 
使 现 有 的 类 添加 了 新 的 方法 ， 也 不 会 影响 新 的 类 。 为 了 进行 更 具体 的 说 明 ， 请 看 下 面 的 例子 ， 
它 用 复合 /转发 的 方法 来 代替 InstrimentedHashSet 类 。 注 意 这 个 实现 分 为 两 部 分 : 类 本 身 和 可 
重用 的 转发 类 (forwarding class)， 包 含 了 所 有 的 转发 方法 ， 没 有 其 他 方法 。 
// Wrapper class - uses composition in place of inheritance 
public class InstrumentedSet<E> extends ForwardingSet<E> { 
private int addCount = 0; 
public InstrumentedSet(Set<E> s) { 


super(s); 


@Override public boolean add(E e) { 
addCount++; 
return super.add(e); 


@Override public boolean addAl1(Collection<? extends E> c) { 
addCount += c.size(); 
return super.addAl1(c); 


} 
public int getAddCount() { 
return addCount; $ 


} 


// Reusable forwarding class 

public class ForwardingSet<E> implements Set<E> { 
private final Set<E> s; d 
public ForwardingSet(Set<E> s) { this.s = s; } 


public void clear() { s.clearQ; } 
public boolean contains(Object o) { return s.contains(o); } 
public boolean isEmpty() { return s.isEmpty(); } 
public int size() { return s.size(Q); } 
public Iterator<E> iterator() { return s.iteratorQ); } 
public boolean add(E e) { return s.add(e); } 
public boolean remove(Object o) { return s.remove(o); } 
public boolean containsAll(Collection<?> c) 

{ return s.containsAll(c); } 


public boolean addAl1(Collection<? extends E> c) 
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{ return s.addAl11(c); } 
public boolean removeAl1(Collection<?> c) 
{ return s.removeAl11(c); } 
public boolean retainAl](Collection<?> c)’ 
{ return s.retainAll(c); } 
public Object[] toArray() { return s.toArray(); } 
public <T> T[] toArray(T[] a) { return s.toArray(a); } 
@Override public boolean equals(Object o) 
z { return s.equals(o); } 
@Override public int hashCode() { return s.hashCode(); } 
@Override public String toString) { return s.toString(); } 
} 


Set 接 口 的 存在 使 得 InstrumentedSet 类 的 设计 成 为 可 能 ， 因为 Set 接 口 保 存 了 HashSet 类 的 
功能 特性 。 除 了 获得 健壮 性 之 外 ， 这 种 设计 也 带 来 了 格外 的 灵活 性 。InstrumentedSet 类 实现 
了 Set 接 口 ， 并 且 拥 有 单个 构造 器 ， 它 的 参数 也 是 Set 类 型 。 从 本 质 上 讲 ， 这 个 类 把 一 个 Set 转 
变 成 了 另 一 个 Set， 同 时 增加 了 计数 的 功能 。 前 面 提 到 的 基于 继承 的 方法 只 适用 于 单个 具体 的 
类 ， 并 且 对 于 超 类 中 所 支持 的 每 个 构造 器 都 要 求 有 一 个 单独 的 构造 器 ， 与 此 不 同 的 是 ， 这 里 
的 包装 类 (wrapper class) 可 以 被 用 来 包装 任何 Set 实 现 ， 并 且 可 以 结合 任何 先前 存在 的 构造 
器 一 起 工作 。 例 如 : 


Set<Date> s = new InstrumentedSet<Date> (new TreeSet<Date>(cmp)); 
Set<E> s2 = new InstrumentedSet<E>(new HashSet<E>(capacity)); 


InstrumentedSet 类 甚至 也 可 以 用 来 临时 替换 一 个 原本 没有 计数 特性 的 Set 实 例 ， 


static void walk(Set<Dog> dogs) { 
InstrumentedSet<Dog> iDogs = new InstrumentedSet<Dog> (dogs); 
-.. // Within this method use iDogs instead of dogs 
} 
因为 每 一 个 InstrumentedSet 实 例 都 把 另 一 个 Set 实 例 包装 起 来 了 ， 所 以 InstrumentedSet 类 
被 称 做 包装 类 (wrapper class), 这 也 正 是 Decorator 模 式 [Gamma95， P.175]， 因 为 
InstrumentedSet 类 对 一 个 集合 进行 了 修饰 ， 为 它 增 加 了 计数 特性 。 有 时 候 ， 复 合 和 转发 的 结 
合 也 被 错误 地 称 为 “委托 (delegation)”。 从 技术 的 角度 而 言 ， 这 不 是 委托 ， 除非 包装 对 象 把 
自身 传递 给 被 包装 的 对 象 [Gamma95, p. 20]。 


包装 类 几乎 没有 什么 缺点 。 需 要 注意 的 一 点 是 ， 包 装 类 不 适合 用 在 回调 框架 (callback 
framework) 中 ， 在 回调 框架 中 ， 对 象 把 自身 的 引用 传递 给 其 他 的 对 象 ， 用 于 后 续 的 调用 
( 回调 ")。 因 为 被 包装 起 来 的 对 象 并 不 知道 它 外 面 的 包装 对 象 ， 所 以 它 传 递 二 个 指向 自身 的 
引用 (this)， 回 调 时 避 开 了 外 面 的 包装 对 象 。 这 被 称 为 SELF 问题 [Lieberman86]。 有 些 人 担心 
转发 方法 调用 所 带 来 的 性 能 影响 ， 或 者 包装 对 象 导 致 的 内 存 占用 。 在 实践 中 ， 这 两 者 都 不 会 
造成 很 大 的 影响 。 编 写 转发 方法 倒是 有 点 琐碎 ， 但 是 只 需要 给 每 个 接口 编写 二 次 构造 器 ， 转 
发 类 则 可 以 通过 包含 接口 的 包 替 你 提供 。 
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只 有 当 子 类 真正 是 超 类 的 子 类 型 (subtype) 时 ， 才 适合 用 继承 。 换 句 话 说 ， 对 于 两 个 类 
A 和 B， 只 有 当 两 者 之 间 确 实 存在 “is-a” 关 系 的 时 候 ， 类 B 才 应 该 扩展 类 A。 如 果 你 打算 让 类 
B 扩 展 类 A， 就 应 该 问 问 自己 : 每 个 B 确 实 也 是 A 吗 ? 如 果 你 不 能 够 确定 这 个 问题 的 答案 是 肯定 
的 ， 那 么 B 就 不 应 该 扩展 A。 如 果 答 案 是 否定 的 ， 通 常情 况 下 ，B 应 该 包含 A 的 一 个 私有 实例 ， 
并 且 暴 露 一 个 较 小 的 、 较 简单 的 API: A 本 质 上 不 是 B 的 一 部 分 ， 只 是 它 的 实现 细节 而 已 。 


在 Java 平 台 类 库 中 ， 有 许多 明显 违反 这 条 原则 的 地 方 。 例 如 ， 栈 (stack) 并 不 是 向 量 
(vector), ， 所 以 Stack 不 应 该 扩展 Vector 同样 地 ， 属 性 列表 也 不 是 散 列 表 ， 所 以 Properties 不 
应 该 扩展 Hashtable。 在 这 两 种 情况 下 ， 复 合 模式 才 是 恰当 的 。 


如 果 在 适合 于 使 用 复合 的 地 方 使 用 了 继承 ， 则 会 不 必要 地 暴露 实现 细节 。 这 样 得 到 的 API 
会 把 你 限制 在 原始 的 实现 上 ， 永 远 限 定 了 类 的 性 能 。 更 为 严重 的 是 ， 由 于 暴露 了 内 部 的 细节 ， 
客户 端 就 有 可 能 直接 访问 这 些 内 部 细节 。 这 样 至 少 会 导致 语义 上 的 混淆 。 例 如 ， 如 果 p 指 向 
Properties 实 例 ， 那 么 p.getProperty(key) 就 有 可 能 产生 与 p.get(key) 不 同 的 结果 : 前 者 考虑 了 
默认 的 属性 表 ， 而 后 者 是 继承 自 Hashtable 的 ， 它 则 没有 考虑 默认 属性 列表 。 最 严重 的 是 ， 客 
户 有 可 能 直接 修改 超 类 ， 从 而 破坏 子 类 的 约 东 条件。 在 Properties 的 情形 中 ， 设 计 者 的 目标 是 ， 
只 允许 字符 串 作 为 键 (key) 和 值 (value) ， 但 是 直接 访问 底层 的 Hashtable 就 可 以 违反 这 种 约 
束 条 件 。 一 旦 违反 了 约束 条 件 ， 就 不 可 能 再 使 用 Properties API 的 其 他 部 分 (load 和 store) T. 
等 到 发 现 这 个 问题 时 ， 要 改正 它 已 经 太 晚 了 ， 因 为 客户 端 依赖 于 使 用 非 字 符 串 的 键 和 值 了 。 


在 决定 使 用 继承 而 不 是 复合 之 前 ， 还 应 该 问 自 己 最 后 一 组 问题 。 对 于 你 正 试图 扩展 的 类 ， 
它 的 API 中 有 没有 缺陷 呢 ? 如 果 有 ， 你 是 否 愿 意 把 那些 缺陷 传播 到 类 的 API 中 ? 继承 机 制 会 把 
超 类 API 中 的 所 有 缺陷 传播 到 子 类 中 ， 而 复合 则 允许 设计 新 的 API 来 隐藏 这 些 缺 陷 。 


简 而 言 之 ， 继 承 的 功能 非常 强大 ， 但 是 也 存在 诸多 问题 ， 因 为 它 违背 了 封装 原则 。 只 有 当 
子 类 和 超 类 之 间 确 实 存在 子 类 型 关系 时 ， 使 用 继承 才 是 恰当 的 。 即 便 如 此 ， 如 果子 类 和 超 类 
处 在 不 同 的 包 中 ， 并 且 超 类 并 不 是 为 了 继承 而 设计 的 ， 那 么 继承 将 会 导致 脆弱 性 (fragility). 
为 了 避免 这 种 脆弱 性 ， 可 以 用 复合 和 转发 机 制 来 代替 继承 ， on ee ne AR 
现 包装 类 的 时 候 。 包 装 类 不 仅 比 子 类 更 加 健壮 ， 而 且 功能 也 更 加 强大 。 


Spade gs ee Oe 
2 i 


es Re 





第 16 条 提醒 我 们 ， 对 于 不 是 为 了 继承 而 设计 、 并 且 没 有 文档 说 明 的 “外 来 ”类 进行 子 类 
化 是 多 么 危险 。 那 么 对 于 专门 为 了 继承 而 设计 并 且 具 有 良好 文档 说 明 的 类 而 言 ， 这 又 意味 着 
什么 呢 ? 


首先 ， 该 类 的 文档 必须 精确 地 描述 覆盖 每 个 方法 所 带 来 的 影响 。 换 名 话说， 该 类 必须 有 文 
档 说 明 它 可 和 覆盖 (overridable) 的 方法 的 自用 性 (self-use)。 对 于 每 个 公有 的 或 受 保护 的 方 
法 或 者 构造 器 ， 它 的 文档 必须 指明 该 方法 或 者 构造 器 调用 了 哪些 可 覆盖 的 方法 ， 是 以 什么 顺 
序 调用 的 ， 每 个 调用 的 结果 又 是 如 何 影 响 后 续 的 处 理 过 程 的 (所谓 可 覆盖 (overridable) 的 方 
法 ， 是 指 非 final 的 ， 公 有 的 或 受 保护 的 ) 。 更 一 般 地 ， 类 必须 在 文档 中 说 明 ， 在 哪些 情况 下 它 
会 调用 可 覆盖 的 方法 。 例 如 ， 后 台 的 线程 或 者 静态 的 初始 化 器 (initializer) 可 能 会 调用 这 样 
的 方法 。 


按 惯例 ， 如 果 方 法 调用 到 了 可 覆盖 的 方法 ， 在 它 的 文档 注释 的 末尾 应 该 包含 关于 这 些 调用 
的 描述 信息 。 这 段 描述 信息 要 以 这 样 的 句子 开头 :“This implementation. (该 实现 …… rt. 
这 样 的 句子 不 应 该 被 认为 是 在 表明 该 行为 可 能 会 随 着 版 本 的 变迁 而 改变 。 它 意 味 着 这 段 描述 
关注 该 方法 的 内 部 工作 情况 。 下 面 是 个 示例 ， 摘自 java.util.AbstractCollection 的 规范 ， 


public boolean remove(Object o) 


Removes a single instance of the specified element from this collection, if it is present 
(optional operation). More formally, removes an element e such that (o==null ? 
e==null: o.equals(e)), if the collection contains one or more such elements. 
Returns true if the collection contained the specified element (or equivalently, if the 


collection changed as a result of the call). 


This implementation iterates over the collection looking for the specified element. If it 
finds the element, it removes the element from the collection using the iterator’s remove 
method. Note that this implementation throws an UnsupportedOperation- 
Exception if the iterator returned by this collection’s iterator method does not 


implement the remove method. 


(如 果 这 个 集合 中 存在 指定 的 元 素 ， 就 从 中 删除 该 指定 元 素 中 的 单个 实例 (这 是 项 可 选 
的 操作 ) 。 更 一 般 地 ， 如 果 集 合 中 包含 一 个 或 者 多 个 这 样 的 元 素 e， 就 从 中 删除 这 种 元 素 ， 
以 便 (o==null ? e==null: o.equals(e)), 如 果 集合 中 包含 指定 的 元 素 ， 就 返回 true (如 果 
调用 最 终 改变 了 集合 ， 也 一 样 )。 
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remove 方 法 将 之 从 集合 中 删除 。 注 意 ， 如 果 由 该 集合 的 iterator 方 法 返回 的 迭代 器 没有 
实现 remove 方 法 ， 该 实现 就 会 抛 出 UnsupportedOperationException ) 


该 文档 清楚 地 说 明了 ， 和 覆盖 iterator 方 法 将 会 影响 remove 方 法 的 行为 。 而 且 ， 它 确切 地 描 
述 了 iterator 方 法 返回 的 Iterator 的 行为 将 会 怎样 影响 remove 方 法 的 行为 。 与 此 相反 的 是 ， 在 第 
16 条 的 情形 中 ， 程 序 员 在 子 类 化 HashSet 的 时 候 ， 并 无 法 说 明 覆 盖 add 方 法 是 否 会 影响 addAll 
方法 的 行为 。 


关于 程序 文档 有 句 格言 : 好 的 API 文 档 应 该 描述 一 个 给 定 的 方法 做 了 什么 工作 ， 而 不 是 描 
述 它 是 如 何 做 到 的 。 那 么 ， 上 面 这 种 做 法 是 否 违背 了 这 句 格 言 呢 ? 是 的 ， 它 确实 违背 了 ! 这 
正 是 继承 破坏 了 封装 性 所 带 来 的 不 幸 后 果 。 所 以 ， 为 了 设计 一 个 类 的 文档 ， 以 便 它 能 够 被 安 
全 地 子 类 化 ， 你 必须 描述 清楚 那些 有 可 能 未 定义 的 实现 细节 。 


为 了 继承 而 进行 的 设计 不 仅仅 涉及 自用 模式 的 文档 设计 。 为 了 使 程序 员 能 够 编写 出 更 加 有 
效 的 子 类 ， 而 无 需 承受 不 必要 的 痛苦 ， 类 必须 通过 某 种 形式 提供 适当 的 钧 子 (hook) ， 以 便 能 
够 进入 到 它 的 内 部 工作 流程 中 ， 这 种 形式 可 以 是 精心 选择 的 受 保护 的 (protected) 方法 ， 也 
可 以 是 受 保护 的 域 ， 后 者 比较 少见 。 例 如 ， 考 虑 java.util.AbstractList 中 的 removeRange 方 法 : 


protected void removeRange(int fromIndex, int toIndex) 


Removes from this list all of the elements whose index is between fromIndex, inclusive, 
and toIndex, exclusive. Shifts any succeeding elements to the left (reduces their index). 
This call shortens the ArrayList by (toIndex-fromIndex) elements. (If 


toIndex==fromIndex, this operation has no effect.) 


This method is called by the clear operation on this list and its sublists. Overriding this 
method to take advantage of the internals of the list implementation can substantially 


improve the performance of the clear operation on this list and its sublists. 


This implementation gets a list iterator positioned before fromIndex and repeatedly 
calls ListIterator.next followed by ListIterator.remove, until the entire 
range has been removed. Note: If List Iterator.remove requires linear time, this 


implementation requires quadratic time. 
Parameters: 
fromIndex index of first element to be removed. 


toIndex index after last element to be removed. 
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(从 列表 中 删除 所 有 索引 处 于 fromIndex ( 含 ) 和 toIndex (不 含 ) 之 间 的 元 素 。 将 所 有 
符合 条 件 的 元 素 移 到 左边 ( 减 小 索引 ) 。 这 一 调用 将 从 ArrayList 中 删除 (toIndex- 
fromIndex) 之 间 的 元 素 。( 如 果 toIndex == fromIndex， 这 项 操作 就 无 效 。) 


这 个 方法 是 通过 clear 操 作 在 这 个 列表 及 其 子 列表 中 调用 的 。 覆盖 这 个 方法 来 利用 列表 
实现 的 内 部 信息 ， 可 以 充分 地 改善 这 个 列表 及 其 子 列表 中 的 clear 操 作 的 性 能 。 


这 项 实现 获得 了 一 个 处 在 fromIndex 之 前 的 列表 迭代 器 ， 并 依次 地 重复 调用 ListIteratorremove 
和 ListIterator.next， 直 到 整个 范围 都 被 移 除 为 止 。 注 意 : 如 果 ListIterator.remove 需 要 线性 的 时 
间 ， 该 实现 就 需要 平方 级 的 时 间 。 


BK: 
fromIndex 要 移 除 的 第 一 个 元 素 的 索引 
toIndex 要 移 除 的 最 后 一 个 元 素 之 后 的 索引 ) 


这 个 方法 对 于 List 实 现 的 最 终 用 户 并 没有 意义 。 提 供 该 方法 的 唯一 目的 在 于 ， 使 子 类 更 易 
于 提供 针对 子 列表 (sublist) 的 快速 clear 方 法 。 如 果 没 有 removeRange 方 法 ， 当 在 子 列 表 
(sublist) 上 调用 clear 方 法 时 ， 子 类 将 不 得 不 用 平方 级 的 时 间 (quadratic performance) 来 完 
成 它 的 工作 > 否则 ， 就 得 重新 编写 整个 subList 机 制 一 一 这 可 不 是 件 容易 的 事情 ! 


因此 ， 当 你 为 了 继承 而 设计 类 的 时 候 ， 如 何 决定 应 该 暴露 哪些 受 保护 的 方法 或 者 域 呢 ? 中 
憾 的 是 ， 并 没有 神奇 的 法 则 可 供 你 使 用 。 你 所 能 做 到 的 最 佳 途径 就 是 努力 思考 ， 发 挥 最 好 的 
想像 ， 然 后 编写 一 些 子 类 进行 测试 。 你 应 该 尽 可 能 少 地 暴露 受 保护 的 成 员 ， 因 为 每 个 方法 或 
者 域 都 代表 了 一 项 关于 实现 细节 的 承诺 。 另 一 方面 ， 你 又 不 能 暴露 得 太 少 ， 因 为 漏 掉 的 受 保 
护 方 法 可 能 会 导致 这 个 类 无 法 被 真正 用 于 继承 。 


对 于 为 了 继承 而 设计 的 类 ,唯一 的 测试 方法 就 是 编写 子 类 。 如果 遗 漏 了 关键 的 受 保护 成 员 ， 
尝试 编写 子 类 就 会 使 遗漏 所 带 来 的 痛苦 变 得 更 加 明显 。 相 反 ， 如 果 编 写 了 多 个 子 类 ， 并 且 无 
一 使 用 受 保护 的 成 员 ， 或 许 就 应 该 把 它 做 成 私有 的 。 经 验 表 明 ，3 个 子 类 通常 就 足以 测试 一 个 
可 扩展 的 类 。 除 了 超 类 的 创建 者 之 外 ， 都 要 编写 一 个 或 者 多 个 这 种 子 类 。 


在 为 了 继承 而 设计 有 可 能 被 广泛 使 用 的 类 时 ， 必 须要 意识 到 ， 对 于 文档 中 所 说 明 的 自用 模 
式 (self-use pattern) ， 以 及 对 于 其 受 保护 方法 和 域 中 所 隐 含 的 实现 策略 ， 你 实际 上 已 经 做 出 
了 永久 的 承诺 。 这 些 承诺 使 得 你 在 后 续 的 版 本 中 提高 这 个 类 的 性 能 或 者 增加 新 功能 都 变 得 非 
常 困难 ， 甚 至 不 可 能 。 因 此 ， 必 须 在 发 布 类 之 前 先 编写 子 类 对 类 进行 测试 。 


还 要 注意 ， 因 继承 而 需要 的 特殊 文档 会 打 乱 正常 的 文档 信息 ， 普 通 的 文档 被 设计 用 来 让 程 
序 员 可 以 创建 该 类 的 实例 ， 并 调用 类 中 的 方法 。 在 编写 本 书 之 时 ， 几 乎 还 没有 适当 的 工具 或 
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者 注释 规范 ， 能 够 把 “普通 的 API 文 档 ” 与 “专门 针对 实现 子 类 的 程序 员 的 信息 ”分 开 来 。 


为 了 允许 继承 ， 类 还 必须 遵守 其 他 一 些 约束 。 构 造 器 决 不 能 调用 可 被 覆盖 的 方法 ， 无 论 是 
直接 调用 还 是 间接 调用 。 如 果 违 反 了 这 条 规则 ， 很 有 可 能 导致 程序 失败 。 超 类 的 构造 器 在 子 
类 的 构造 器 之 前 运行 ， 所 以 ， 子 类 中 覆盖 版 本 的 方法 将 会 在 子 类 的 构造 器 运行 之 前 就 先 被 调 
用 。 如 果 该 覆盖 版 本 的 方法 依赖 于 子 类 构造 器 所 执行 的 任何 初始 化 工作 ， 该 方法 将 不 会 如 预 
期 般 地 执行 。 为 了 更 加 直观 地 说 明 这 一 点 ， 下 面 举 个 例子 ， 其 中 有 个 类 违反 了 这 条 规则 : 


public class Super { 
// Broken - constructor invokes an overridable method 


public Supero) { 
overrideMe(); 

} 

public void overrideMe() { 


} 


下 面 的 子 类 覆盖 了 方法 overrideMe，Super 唯 一 的 构造 器 就 错误 地 调用 了 这 个 方法 : 


public final class Sub extends Super { 
private final Date date; // Blank final, set by constructor 


SubQ { 
date = new Date(); 


// Overriding method invoked by superclass constructor 

@Override public void overrideMe() { 
System.out.printIn(date) ; 

} 


public static void main(String[] args) { 
Sub sub = new Sub(); 
sub.overrideMe() ; 

} : . 

你 可 能 会 期 待 这 个 程序 会 打印 出 日 期 两 次 ， 但 是 它 第 一 次 打印 出 的 是 null， 因 为 overrideMe 
方法 被 Super 构 造 器 调用 的 时 候 ， 构 造 器 Sub 还 没有 机 会 初始 化 date 域 。 注意， 这 个 程序 观察 到 
的 final 域 处 于 两 种 不 同 的 状态 。 还 要 注意 ， 如 果 overrideMe 已 经 调用 了 date 中 的 任何 方法 ， 当 
Super 构 造 器 调用 overrideMe 的 时 候 ， 调 用 就 会 抛 出 NullPointerException 异 常 。 如 果 该 程序 没 
有 抛 出 NullPointerException 异 常 ， 唯 一 的 原因 就 在 于 println 方 法 对 于 处 理 null 参 数 有 着 特殊 的 


规定 。 


在 为 了 继承 而 设计 类 的 时 候 ，Cloneable 和 Serializable 接 口 出 现 了 特殊 的 困难 。 如 果 类 是 
为 了 继承 而 被 设计 的 ， 无 论 实 现 这 其 中 的 哪个 接口 通常 都 不 是 个 好 主意 ， 因 为 它们 把 一 些 实 
质 性 的 负担 转嫁 到 了 扩展 这 个 类 的 程序 员 的 身上 。 然 而 ， 你 还 是 可 以 采取 一 些 特殊 的 手段 ， 
使 得 子 类 实现 这 些 接口 ， 无 需 强迫 子 类 的 程序 员 去 承受 这 些 负担 。 第 11 条 和 74 条 中 讲述 了 这 
些 特殊 的 手段 。 
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如 果 你 决定 在 一 个 为 了 继承 而 设计 的 类 中 实现 Cloneable 或 者 Serializable 接 口 ， 就 应 该 意 
识 到 ， 因 为 clone 和 readObject 方 法 在 行为 上 非常 类 似 于 构造 器 ， 所 以 类 似 的 限制 规则 也 是 适 
用 的 : 无 论 是 clone 还 是 readObject， 都 不 可 以 调用 可 敌 盖 的 方法 ， 不 管 是 以 直接 还 是 间接 的 
方式 。 对 于 readObject 方 法 ， 覆 盖 版 本 的 方法 将 在 子 类 的 状态 被 反 序列 化 (deserialized) 之 
前 先 被 运行 ， 而 对 于 clone 方 法 ， 和 覆盖 版 本 的 方法 则 是 在 子 类 的 clone 方 法 有 机 会 修正 被 克隆 对 
象 的 状态 之 前 先 被 运行 。 无 论 哪 种 情形 ， 都 不 可 避免 地 将 导致 程序 失败 。 在 clone 方 法 的 情形 
中 ， 这 种 失败 可 能 会 同时 损害 到 原始 的 对 象 以 及 被 克隆 的 对 象 本 身 。 例 如 ， 如 果 和 覆盖 版 本 的 
方法 假设 它 正在 修改 对 象 深层 结构 的 克隆 对 象 的 备份 ， 就 会 发 生 这 种 情况 ， 但 是 该 备份 还 没 
有 完成 。 

最 后 ， 如 果 你 决定 在 一 个 为 了 继承 而 设计 的 类 中 实现 Serializable， 并 且 该 类 有 一 个 
readResolve 或 者 writeReplace 方 法 , 就 必须 使 readResolve 或 者 writeReplace 成 为 受 保护 的 方法 ， 
而 不 是 私有 的 方法 。 如 果 这 些 方 法 是 私有 的 ， 那 么 子 类 将 会 不 声 不 响 地 忽略 掉 这 两 个 方法 。 
这 正 是 “为 了 允许 继承 ， 而 把 实现 细节 变 成 一 个 类 的 API 的 一 部 分 ”的 另 一 种 情形 。 


到 现在 为 止 ， 应 该 很 明显 : 为 了 继承 而 设计 类 ， 对 这 个 类 会 有 一 些 实质 性 的 限制 。 这 并 不 
是 很 轻松 就 可 以 承诺 的 决定 。 在 某 些 情况 下 ， 这 样 的 决定 很 明显 是 正确 的 ， 比 如 抽象 类 ， 包 
括 接口 的 骨架 实现 (skeletal implementation) ( 见 第 18 条 )。 但 是 ， 在 另外 一 些 情 况 下 ， 这 
样 的 决定 却 很 明显 是 错误 的 ， 比 如 不 可 变 的 类 ( 见 第 15 条 ) 。 


但 是 ， 对 于 普通 的 具体 类 应 该 怎么 办 呢 ? 它们 既 不 是 final 的 ， 也 不 是 为 了 子 类 化 而 设计 和 
编写 文档 的 ， 所 以 这 种 状况 很 危险 。 每 次 对 这 种 类 进行 修改 ， 从 这 个 类 扩展 得 到 的 客户 类 就 
有 可 能 遭 到 破坏 。 这 不 仅仅 是 个 理论 问题 。 对 于 一 个 并 非 为 了 继承 而 设计 的 非 final 具 体 类 ， 
在 修改 了 它 的 内 部 实现 之 后 ， 接 收 到 与 子 类 化 相关 的 错误 报告 也 并 不 少见 。 


这 个 问题 的 最 佳 解 决 方案 是 ， 对 于 那些 并 非 为 了 安全 地 进行 子 类 化 而 设计 和 编写 文档 的 
类 ， 要 禁止 子 类 化 。 有 两 种 办 法 可 以 禁止 子 类 化 。 比 较 容 易 的 办 法 是 把 这 个 类 声明 为 final 的 。 
另 一 种 办 法 是 把 所 有 的 构造 器 都 变 成 私有 的 ， 或 者 包 级 私有 的 ， 并 增加 一 些 公有 的 静态 工厂 
来 替代 构造 器 。 后 一 种 办 法 在 第 15 条 中 讨论 过 ， 它 为 内 部 使 用 子 类 提供 了 灵活 性 。 这 两 种 办 
法 都 是 可 以 接受 的 。 


这 条 建议 可 能 会 引 来 争议 ， 因 为 许多 程序 员 已 经 习惯 于 对 普通 的 具体 类 进行 子 类 化 ， 以 便 
增加 新 的 功能 设施 ， 比 如 仪表 功能 (instrumentation， 如 计数 显示 等 )、 通 知 机 制 或 者 同步 功 
能 ， 或 者 为 了 限制 原 有 类 中 的 功能 。 如 果 类 实现 了 某 个 能 够 反映 其 本 质 的 接口 ， 比 如 Set、 
List Map, 就 不 应 该 为 了 禁止 子 类 化 而 感到 后 悔 。 第 16 条 中 介绍 的 包装 类 (wrapper class) 
模式 提供 了 另 一 种 更 好 的 办 法 ， 让 继承 机 制 实现 更 多 的 功能 。 


如 果 具 体 的 类 没有 实现 标准 的 接口 ， 那 么 禁止 继承 可 能 会 给 有 些 程序 员 带 来 不 便 。 如 果 你 
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认为 必须 允许 从 这 样 的 类 继承 ， 一 种 合理 的 办 法 是 确保 这 个 类 永远 不 会 调用 它 的 任何 可 覆盖 
的 方法 ， 并 在 文档 中 说 明 这 一 点 。 换 句 话 说， 完全 消除 这 个 类 中 可 覆盖 方法 的 自用 特性 。 这 
样 做 之 后 ， 就 可 以 创建 “能 够 安全 地 进行 子 类 化 ”的 类 。 和 覆盖 方法 将 永远 也 不 会 影响 其 他 任 
何方 法 的 行为 。 


你 可 以 机 械 地 消除 类 中 可 覆盖 方法 的 自用 特性 ， 而 不 改变 它 的 行为 。 将 每 个 可 覆盖 方法 的 
代码 体 移 到 一 个 私有 的 “辅助 方法 (helper method)” 中 ,并且 让 每 个 可 覆盖 的 方法 调用 它 的 
私有 辅助 方法 。 然后， 用 “直接 调用 可 覆盖 方法 的 私有 辅助 方法 ”来 代替 “可 覆盖 方法 的 每 
个 自用 调用 ”。 
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Java 程 序 设计 语言 提供 了 两 种 机 制 ， 可 以 用 来 定义 允许 多 个 实现 的 类 型 : 接口 和 抽象 类 。 
这 两 种 机 制 之 间 最 明显 的 区 别 在 于 ， 抽 象 类 允许 包含 某 些 方法 的 实现 ， 但 是 接口 则 不 允许 。 
一 个 更 为 重要 的 区 别 在 于 ， 为 了 实现 由 抽象 类 定义 的 类 型 ， 类 必须 成 为 抽象 类 的 一 个 子 类 。 
任何 一 个 类 ， 只 要 它 定 义 了 所 有 必要 的 方法 ， 并 且 遵 守 通用 约定 ， 它 就 被 允许 实现 一 个 接口 ， 
而 不 管 这 个 类 是 处 于 类 层次 (class hierarchy) 的 哪个 位 置 。 因 为 Java 只 允许 单 继承 ， 所 以 ， 
抽象 类 作为 类 型 定义 受到 了 极 大 的 限制 。 


现 有 的 类 可 以 很 容易 被 更 新 ， 以 实现 新 的 接口 。 如 果 这 些 方法 尚 不 存在 ， 你 所 需要 做 的 就 
只 是 增加 必要 的 方法 ， 然 后 在 类 的 声明 中 增加 一 个 implements 子 句 。 例 如 ， 当 Comparable 接 
口 被 引入 到 Java 平 台中 时 ， 会 更 新 许多 现 有 的 类 ， 以 实现 Comparable 接 口 。 一 般 来 说 ， 无 法 
更 新 现 有 的 类 来 扩展 新 的 抽象 类 。 如 果 你 希望 让 两 个 类 扩展 同一 个 抽象 类 ， 就 必须 把 抽象 类 
放 到 类 型 层次 (type hierarchy) 的 高 处 ， 以 便 这 两 个 类 的 一 个 祖先 成 为 它 的 子 类 。 遗 憾 的 是 ， 
这 样 做 会 间接 地 伤害 到 类 层次 ， 迫 使 这 个 公共 祖先 的 所 有 后 代 类 都 扩展 这 个 新 的 抽象 类 ， 无 
论 它 对 于 这 些 后 代 类 是 否 合适 。 


接口 是 定义 mixin (混合 类 型 ) 的 理想 选择 。 不 严格 地 讲 ，mixin 是 指 这 样 的 类 型 ， 类 除了 
实现 它 的 “基本 类 型 (primary type)” 之 外 ， 还 可 以 实现 这 个 mixin 类 型 ， 以 表明 它 提供 了 蘑 
些 可 供 选 择 的 行为 。 例 如 ，Comparable 是 一 个 mixin 接 口 ， 它 允许 类 表明 它 的 实例 可 以 与 其 他 
的 可 相互 比较 的 对 象 进行 排序 。 这 样 的 接口 之 所 以 被 称 为 mixin， 是 因为 它 允 许 任 选 的 功能 可 
被 混合 到 类 型 的 主要 功能 中 。 抽 象 类 不 能 被 用 于 定义 mixin， 同 样 也 是 因为 它们 不 能 被 更 新 到 
现 有 的 类 中 : 类 不 可 能 有 一 个 以 上 的 父 类 ， 类 层次 结构 中 也 没有 适当 的 地 方 来 插入 mixin 。 


接口 允许 我 们 构造 非 层 次 结构 的 类 型 框架 。 类 型 层次 对 于 组 织 某 些 事物 是 非常 合适 的 ， 但 
是 其 他 有 些 事物 并 不 能 被 整齐 地 组 织 成 一 个 严格 的 层次 结构 。 例 如 ， 假 设 我 们 有 一 个 接口 代 
表 一 个 singer (歌唱 家 ) ， 另 一 个 接口 代表 一 个 songwriter (作曲 家 ): 


public interface Singer { 
AudioClip sing(Song s); 


public interface Songwriter { 
Song compose(boolean hit); 


在 现实 生活 中 ， 有 些 歌 唱 家 本 身 也 是 作曲 家 。 因 为 我 们 使 用 了 接口 而 不 是 抽象 类 来 定义 这 
些 类 型 ， 所 以 对 于 单个 类 而 言 ， 它 同时 实现 Singer 和 Songwriter 是 完全 允许 的 。 实 际 上 ， 我们 
可 以 定义 第 三 个 接口 ， 它 同时 扩展 了 Singer 和 Songwriter， 并 添加 了 一 些 适合 于 这 种 组 合 的 新 
方法 : 
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public interface SingerSongwriter extends Singer, Songwriter { 
AudioClip strum(); 
void actSensitive(); 

} 


你 并 不 总 是 需要 这 种 灵活 性 ， 但 是 一 旦 你 这 样 做 了 ， 接 口 可 就 成 了 救世 主 ， 能 帮助 你 解决 
大 问题 。 另 外 一 种 做 法 是 编写 一 个 腔 肿 (bloated) 的 类 层次 ， 对 于 每 一 种 要 被 支持 的 属性 组 
合 ， 都 包含 一 个 单独 的 类 。 如 果 在 整个 类 型 系统 中 有 n 个 属性 ， 那 么 就 必须 支持 2" 种 可 能 的 组 
合 。 这 种 现象 被 称 为 “组 合 爆炸 (combinatorial explosion)”, 3 Ave BEM | BK th BE, 
这 些 类 包含 许多 方法 ， 并 且 这 些 方法 只 是 在 参数 的 类 型 上 有 所 不 同 而 已 ， 因 为 类 层次 中 没有 
任何 类 型 体现 了 公共 的 行为 特征 。 


通过 第 16 条 中 介绍 的 包装 类 (wrapper class) 模式 ， 接 口 使 得 安全 地 增强 类 的 功能 成 为 
可 能 。 如 果 使 用 抽象 类 来 定义 类 型 ， 那 么 程序 员 除了 使 用 继承 的 手段 来 增加 功能 ， 没 有 其 他 
的 选择 。 这 样 得 到 的 类 与 包装 类 相 比 ， 功 能 更 差 ， 也 更 加 脆弱 。 


虽然 接口 不 允许 包含 方法 的 实现 ， 但 是 ， 使 用 接口 来 定义 类 型 并 不 妨碍 你 为 程序 员 提 供 实 
现 上 的 帮助 。 通 过 对 你 导出 的 每 个 重要 接口 都 提供 一 个 抽象 的 骨架 实现 (skeletal 
implementation) 类 ， 把 接口 和 抽象 类 的 优点 结合 起 来 。 接 口 的 作用 仍然 是 定义 类 型 ， 但 是 
骨架 实现 类 接管 了 所 有 与 接口 实现 相关 的 工作 。 


按照 惯例 ， 骨 架 实 现 被 称 为 AbstractInterface， 这 里 的 Interface 是 指 所 实现 的 接口 的 名 字 。 
例如 ，Collections Framework 为 每 个 重要 的 集合 接口 都 提供 了 一 个 骨架 实现 ， 包 括 
AbstractCollection 、AbstractSet、AbstractList 和 AbstractMap。 将 它们 称 作 SkeletalCollection、 
SkeletalSet、SkeletalList 和 SkeletalMap 也 是 有 道理 的 ， 但 是 现在 Abstract 的 用 法 已 经 根深 
av Al. 


如 果 设 计 得 当 ， 骨 架 实 现 可 以 使 程序 员 很 容易 提供 他 们 自己 的 接口 实现 。 例 如 ， 下 面 是 一 
个 静态 工厂 方法 ， 它 包含 一 个 完整 的 、 功 能 全 面 的 List 实 现 : 


// Concrete implementation built atop skeletal implementation 
static List<Integer> intArrayAsList(final int[] a) { 
if (a == null) 
throw new NullPointerException(); 


return new AbstractList<Integer>() { 
public Integer get(int i) { 
return a[i]; // Autoboxing (Item 5) 


@Override public Integer set(int i, Integer val) { 
int oldVal = a[i]; wee 
a[i] = val; // Auto-unboxing 
return oldVal; // Autoboxing 

} 


public int size() { 
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return a.length; 


}; 
} 


当 你 考虑 一 个 List 实 现 应 该 为 你 完成 哪些 工作 的 时 候 ， 可 以 看 出 ， 这 个 例子 充分 演示 了 骨 
架 实 现 的 强大 功能 。 顺 便 提 一 下 ， 这 个 例子 是 个 Adapter[Gamma95, p.139]， 它 允许 将 int 数 组 
看 作 Integer 实 例 的 列表 。 由 于 在 int 值 和 Integer 实 例 之 间 来 回转 换 需要 开销 ， 它 的 性 能 不 会 很 
好 。 注 意 ， 这 个 例子 中 只 提供 一 个 静态 工厂 ， 并 且 这 个 类 还 是 个 不 可 被 访问 的 匿名 类 
(anonymous class) ( 见 第 22 条 ) ， 它 被 隐藏 在 静态 工厂 的 内 部 。 


骨架 实现 的 美妙 之 处 在 于 ， 它 们 为 抽象 类 提供 了 实现 上 的 帮助 ， 但 又 不 强加 “抽象 类 被 用 
作 类 型 定义 时 ”所 特有 的 严格 限制 。 对 于 接口 的 大 多 数 实现 来 讲 ， 扩 展 骨 架 实现 类 是 个 很 显 
然 的 选择 ， 但 并 不 是 必需 的 。 如 果 预 置 的 类 无 法 扩展 骨架 实现 类 ， 这 个 类 始终 可 以 手工 实现 
这 个 接口 。 此 外 ， 上 骨架 实现 类 仍然 能 够 有 助 于 接口 的 实现 。 实 现 了 这 个 接口 的 类 可 以 把 对 于 
接口 方法 的 调用 ， 转 发 到 一 个 内 部 私有 类 的 实例 上 ， 这 个 内 部 私有 类 扩展 了 骨架 实现 类 。 这 
种 方法 被 称 作 模拟 多 重 继承 (simulated multiple inheritance) ， 它 与 第 16 条 中 讨论 的 包装 类 
模式 密切 相关 。 这 项 技术 具有 多 重 继承 的 绝 大 多 数 优点 ， 同 时 又 避免 了 相应 的 缺陷 。 


编写 骨架 实现 类 相对 比较 简单 ， 只 是 有 点 单调 乏味 。 首 先 ， 必 须 认 真 研究 接口 ， 并 确定 哪 
些 方法 是 最 为 基本 的 (Primitive) ， 其 他 的 方法 则 可 以 根据 它们 来 实现 。 这 些 基 本 方法 将 成 为 
骨架 实现 类 中 的 抽象 方法 。 然 后 ， 必 须 为 接口 中 所 有 其 他 的 方法 提供 具体 的 实现 。 例 如 ， 下 
面 是 Map.Entry 接 口 的 骨架 实现 类 : 


// Skeletal Implementation 
public abstract class AbstractMapEntry<K,V> 
implements Map.Entry<K,V> { 
// Primitive operations 
public abstract K getKey(); 
public abstract V getValue(); 


// Entries in modifiable maps must override this method 
public V setValue(V value) { 

throw new UnsupportedOperationException(); 
} 


// Implements the general contract of Map.Entry.equals 
@Override public boolean equals(Object o) { 
if (o == this) 
return true; 
if (! (o instanceof Map.Entry)) 
return false; 
Map.Entry<?,?> arg = (Map.Entry) 0; 
return equals(getKey(), arg.getKey()) & 
equals(getValue(), arg.getValue()); 
} ‘ 
private static boolean equals(Object ol, Object o2) { 
return ol == null ? o2 == null : ol.equals(o2); 
} 
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// Implements the general contract of Map.Entry.hashCode 
@Override public int hashCode() { 
return hashCode(getKey()) ^ hashCode(getValue()); 


} 
private static int hashCode(Object obj) { 
return obj == null ? @ : obj.hashCode(); 


} 


因为 骨架 实现 类 是 为 了 继承 的 目的 而 设计 的 ， 所 以 应 该 遵从 第 17 条 中 介绍 的 所 有 关于 设 
计 和 文档 的 指导 原则 。 为 了 简短 起 见 ， ria 但 是 对 于 骨 
架 实现 类 而 言 ， 好 的 文档 绝对 是 非常 必要 的 。 


骨架 实现 上 有 个 小 小 的 不 同 ， 就 是 简单 实现 (simple implementation), AbstractMap. 
SimpleEntry 就 是 个 例子 。 简 单 实 现 就 像 个 骨架 实现 ， 这 是 因为 它 实 现 了 接口 ， 并 且 是 为 了 继 
承 而 设计 的 ， 但 是 区 别 在 于 它 不 是 抽象 的 : 它 是 最 简单 的 可 能 的 有 效 实现 。 你 可 以 原封 不 动 
地 使 用 ， 也 可 以 看 情况 将 它 子 类 化 。 


使 用 抽象 类 来 定义 允许 多 个 实现 的 类 型 ， 与 使 用 接口 相 比 有 一 个 明显 的 优势 : 抽象 类 的 演 
变 比 接口 的 演变 要 容易 得 多 。 如 果 在 后 续 的 发 行 版 本 中 ， 你 希望 在 抽象 类 中 增加 新 的 方法 ， 
始终 可 以 增加 具体 方法 ， 它 包含 合理 的 默认 实现 。 然 后 ， 该 抽象 类 的 所 有 现 有 实现 都 将 提供 
这 个 新 的 方法 。 对 于 接口 ， 这 样 做 是 行 不 通 的 。 


一 般 来 说 ， 要 想 在 公有 接口 中 增加 方法 ， 而 不 破坏 实现 这 个 接口 的 所 有 现 有 的 类 ， 这 是 不 
可 能 的 。 之 前 实现 该 接口 的 类 将 会 漏 掉 新 增加 的 方法 ， 并 且 无 法 再 通过 编译 。 在 为 接口 增加 
新 方法 的 同时 ， 也 为 骨架 实现 类 增加 同样 的 新 方法 ， 这 样 可 以 在 一 定 程度 上 减 小 由 此 带 来 的 
破坏 ,但 是 ， 这 样 做 并 没有 真正 解决 问题 。 所 有 不 从 骨架 实现 类 继承 的 接口 实现 仍然 会 遭 到 
破坏 。 


因此 ， 设 计 公 有 的 接口 要 非常 谨慎 。 接 口 一 旦 被 公开 发 行 ， 并 且 已 被 广泛 实现 ， 再 想 改 
变 这 个 接口 几乎 是 不 可 能 的 。 你 必须 在 初次 设计 的 时 候 就 保证 接口 是 正确 的 。 如 果 接 口 包含 
微小 的 瑕 写 ， 它 将 会 一 直 影响 你 以 及 接口 的 用 户 。 如 果 接 口 具有 严重 的 缺陷 ， 它 可 以 导致 API 
彻底 失败 。 在 发 行 新 接口 的 时 候 ， 最 好 的 做 法 是 ， 在 接口 被 “冻结 ”之 前 ,“ 尽 可 能 让 更 多 的 
程序 员 用 尽 可 能 多 的 方式 来 实现 这 个 新 接口 。 这 样 有 助 于 在 依然 可 以 改正 缺陷 的 时 候 就 发 现 
它们 。 


简 而 言 之 ， 接 口 通常 是 定义 允许 多 个 实现 的 类 型 的 最 佳 途径 。 这 条 规则 有 个 例外 ， 即 当 演 
变 的 容易 性 比 灵活 性 和 功能 更 为 重要 的 时 候 。 在 这 种 情况 下 ， 应 该 使 用 抽象 类 来 定义 类 型 ， 
但 前 提 是 必须 理解 并 且 可 以 接受 这 些 局 限 性 。 如 果 你 导出 了 一 个 重要 的 接口 ， 就 应 该 坚决 考 
虑 同时 提供 骨架 实现 类 。 最 后 ， 应 该 尽 可 能 谨慎 地 设计 所 有 的 公有 接口 ， 并 通过 编写 多 个 实 
现 来 对 它们 进行 全 面 的 测试 。 





当 类 实现 接口 时 ， 接 口 就 充当 可 以 引用 这 个 类 的 实例 的 类 型 (type)。 因 此 ， 类 实现 了 接 
口 ， 就 表明 客户 端 可 以 对 这 个 类 的 实例 实施 某 些 动 作 。 为 了 任何 其 他 目的 而 定义 接口 是 不 恰 
当 的 。 


有 一 种 接口 被 称 为 常量 接口 (constant interface) ， 它 不 满足 上 面 的 条 件 。 这 种 接口 没有 
包含 任何 方法 ， 它 只 包含 静态 的 final 域 ， 每 个 域 都 导出 一 个 常量 。 使 用 这 些 常量 的 类 实现 这 
个 接口 ， 以 避免 用 类 名 来 修饰 常量 名 。 下 面 是 一 个 例子 : 


// Constant interface antipattern - do not use! 
public interface PhysicalConstants { 
// Avogadro's number (1/mol) 
static final double AVOGADROS_NUMBER = 6.02214199e23; 


// Boltzmann constant (J/K) 
static final double BOLTZMANN_CONSTANT = 1.3806503e-23; 


// Mass of the electron (kg) 

; static final double ELECTRON_MASS = 9.10938188e-31; 

常量 接口 模式 是 对 接口 的 不 良 使 用 。 类 在 内 部 使 用 某 些 常 量 ， 这 纯粹 是 实现 细节 。 实现 常 
量 接 口 ， 会 导致 把 这 样 的 实现 细节 泄露 到 该 类 的 导出 API 中 。 类 实现 常量 接口 ， 这 对 于 这 个 类 
的 用 户 来 讲 并 没有 什么 价值 。 实 际 上 ， 这 样 做 反而 会 使 他 们 更 加 糊涂 。 更 糟糕 的 是 ， 它 代表 
了 一 种 承诺 : 如果 在 将 来 的 发 行 版 本 中 ， 这 个 类 被 修改 了 ， 它 不 再 需要 使 用 这 些 常量 了 ， 它 
依然 必须 实现 这 个 接口 ， 以 确保 二 进 制 兼容 性 。 如 果 非 final 类 实现 了 常量 接口 ， 它 的 所 有 子 
类 的 命名 空间 也 会 被 接口 中 的 常量 所 “污染 ”。 


在 Java 平 台 类 库 中 有 有 几 个 常量 接口 ， 例 如 java.io.ObjectStreamConstants。 这 些 接口 应 该 
被 认为 是 反面 的 典型 ， 不 值得 效仿 。 


如 果 要 导出 常量 ， 可 以 有 几 种 合理 的 选择 方案 。 如 果 这 些 常量 与 某 个 现 有 的 类 或 者 接口 紧 
密 相 关 ， 就 应 该 把 这 些 常量 添加 到 这 个 类 或 者 接口 中 。 例 如 ， 在 Java 平 台 类 库 中 所 有 的 数值 包 
装 类 ， 如 Integer 和 Double， 都 导出 了 MIN_VALUE 和 MAX_VALUE 常 量 。 如 果 这 些 常量 最 好 
被 看 作 枚 举 类 型 的 成 员 ， 就 应 该 用 枚 举 类 型 (enum type) ( 见 第 30 条 ) 来 导出 这 些 常量 。 否 
则 ， 应 该 使 用 不 可 实例 化 的 工具 类 (utility class) ( 见 第 4 条 ') 来 导出 这 些 常量 。 下 面 的 例子 
是 前 面 的 PhysicalConstants 例 子 的 工具 类 翻版 : 


// Constant utility class 
package com.effectivejava.science; 


public class PhysicalConstants { 
private PhysicalConstants() { } // Prevents instantiation 
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public static final double AVOGADROS_NUMBER = 6,.02214199e23; 
public static final double BOLTZMANN_CONSTANT = 1.3806503e-23; 
public static final double ELECTRON_MASS = 9.10938188e-31; 


工具 类 通常 要 求 客户 端 要 用 类 名 来 修饰 这 些 常量 各， 例如 PhysicalConstants. AVOGADROS_ 
NUMBER。 如 果 大 量 利用 工具 类 导出 的 常量 ， 可 以 通过 利用 静态 导入 (static import) 机 制 ， 
避免 用 类 名 来 修饰 常量 名 ， 不 过 ， 静 态 导入 机 制 是 在 Java 发 行 版 本 1.5 中 才 引入 的 : 


// Use of static import to avoid qualifying constants 
import static com.effectivejava.science.PhysicalConstants.+#; 


public class Test { 
double atoms(double mols) { 
return AVOGADROS_NUMBER * mols; 


// Many more uses of PhysicalConstants justify static import 


简 而 言 之 ， 接 口 应 该 只 被 用 来 定义 类 型 ， 它 们 不 应 该 被 用 来 导出 常量 。 
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有 时 候 ， 可 能 会 遇 到 带 有 两 种 甚至 更 多 种 风格 的 实例 的 类 ， 并 包含 表示 实例 风格 的 标 答 
(tag) 域 。 例 如 , .考虑 下 面 这 个 类 ， 它 能 够 表示 圆 形 或 者 矩形 ; 


// Tagged class - vastly inferior to a class ssa 
class Figure { 
enum Shape { RECTANGLE, CIRCLE }; 


// Tag field - the shape of this figure 
final Shape shape; 


// These fields are used only if shape is RECTANGLE 
double length; 
double width; 


// This field is used only if shape is CIRCLE 
double radius; 


// Constructor for circle 

Figure(double radius) { 
shape = Shape.CIRCLE; 
this.radius = radius; 


// Constructor for rectangle 
Figure(double length, i P een { 
shape = Shape.RECTANG 
this.length = > is 
this.width = width; 


double area() { 
switch(shape) { 
case RECTANGLE: 
return length + width; 
case CIRCLE: 
return Math.PI * (radius * radius); 
default: 
throw new AssertionError(); 
} 


} 
} 


这 种 标签 类 (tagged class) 有 着 许多 缺点 。 它 们 中 充斥 着 样板 代码 ， 包 括 枚 举 声明 、 标 
签 域 以 及 条 件 语 句 。 由 于 多 个 实现 乱七八糟 地 挤 在 了 单个 类 中 ， 破 坏 了 可 读 性 。 内 存 占 用 也 
增加 了 ， 因 为 实例 承担 着 属于 其 他 风格 的 不 相关 的 域 。 域 不 能 做 成 是 final 的 ， 除 非 构造 器 初 
始 化 了 不 相关 的 域 ， 产 生 更 多 的 样板 代码 。 构 造 器 必须 不 借助 编译 器 ， 来 设置 标签 域 ， 并 初 
始 化 正确 的 数据 域 ， 如 果 初 始 化 了 错误 的 域 ， 程 序 就 会 在 运行 时 失败 。 无 法 给 标签 类 添加 风 
格 ， 除 非 可 以 修改 它 的 源 文件 。 如 果 一 定 要 添加 风格 ， 就 必须 记得 给 每 个 条 件 语 句 都 添加 一 
个 条 件 ， 否 则 类 就 会 在 运行 时 失败 。 最 后 ， 实例 的 数据 类 型 没有 提供 任何 关于 其 风格 的 线索 。 
一 名 话 ， 标 签 类 过 于 宛 长、 容易 出 错 ， 并 且 效 率 低下 。 
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幸运 的 是 ， 面 向 对 象 的 语言 例如 Java， 就 提供 了 其 他 更 好 的 方法 来 定义 能 表示 多 种 风格 对 
象 的 单个 数据 类 型 : 子 类 型 化 (subtyping) 。 标 签 类 正 是 类 层次 的 一 种 简单 的 仿效 。 


为 了 将 标签 类 转变 成 类 层次 ， 首 先 要 为 标签 类 中 的 每 个 方法 都 定义 一 个 包含 抽象 方法 的 抽 
象 类 ， 这 每 个 方法 的 行为 都 依赖 于 标签 值 。 在 Figure 类 中 ， 只 有 一 个 这 样 的 方法 : area。 这 个 
抽象 类 是 类 层次 的 根 (root) 。 如 果 还 有 其 他 的 方法 其 行为 不 依赖 于 标签 的 值 ， 就 把 这 样 的 方 
法 放 在 这 个 类 中 。 同 样 地 ， 如 果 所 有 的 方法 都 用 到 了 某 些 数据 域 ， 就 应 该 把 它们 放 在 这 个 类 
中 。 在 Figure 类 中 ， 不 存在 这 种 类 型 独立 的 方法 或 者 数据 域 。 


接 下 来 ,为 每 种 原始 标签 类 都 定义 根 类 的 具体 子 类 。 在 前 面 的 例子 中 , 这 样 的 类 型 有 两 个 : 
WIE (circle) 和 和 矩形 (rectangle) 。 在 每 个 子 类 中 都 包含 特定 于 该 类 型 的 数据 域 。 在 我 们 的 示 
例 中 ，radius 是 特定 于 圆 形 的 ，length 和 width 是 特定 于 矩形 的 。 同 时 在 每 个 子 类 中 还 包括 针对 
根 类 中 每 个 抽象 方法 的 相应 实现 。 以 下 是 与 原始 的 Figure 类 相对 应 的 类 层次 : 


// Class hierarchy replacement for a tagged class 
abstract class Figure { 
abstract double area(); 


class Circle extends Figure { 
final double radius; 
Circle(double radius) { this.radius = radius; } 


double area() { return Math.PI * (radius + radius); } 


class Rectangle extends Figure { 
final double length; 
final double width; 
Rectangle(double length, double width) { 
this.length = length; 
this.width = width; 


} 
double area() { return length * width; } 
} 


这 个 类 层次 纠正 了 前 面 提 到 过 的 标签 类 的 所 有 缺点 。 这 段 代 码 简单 且 清楚 ， 没 有 包含 在 原 
来 的 版 本 中 所 见 到 的 所 有 样板 代码 。 每 个 类 型 的 实现 都 配 有 自己 的 类 ， 这 些 类 都 没有 受到 不 
相关 的 数据 域 的 拖累 。 所 有 的 域 都 是 final 的 。 编 译 器 确保 每 个 类 的 构造 器 都 初始 化 它 的 数据 
域 ， 对 于 根 类 中 声明 的 每 个 抽象 方法 ， 都 确保 有 一 个 实现 。 这 样 就 杜绝 了 由 于 遗漏 switch case 
而 导致 运行 时 失败 的 可 能 性 。 多 个 程序 员 可 以 独立 地 扩展 层次 结构 ， 并 且 不 用 访问 根 类 的 源 
代码 就 能 相互 操作 。 每 种 类 型 都 有 一 种 相关 的 独立 的 数据 类 型 ， 允 许 程序 员 指 明 变 量 的 类 型 ， 
限制 变量 ， 并 将 参数 输入 到 特殊 的 类 型 。 


类 层次 的 另 一 种 好 处 在 于 ， 它 们 可 以 用 来 反映 类 型 之 间 本 质 上 的 层次 关系 ， 有 助 于 增强 灵 
活性 ， 并 进行 更 好 的 编译 时 类 型 检查 。 假 设 上 述 例子 中 的 标签 类 也 允许 表达 正方 形 。 类 层次 
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可 以 反映 出 正方 形 是 一 种 特殊 的 矩形 这 一 事实 (假设 两 者 都 是 不 可 变 的 ): 


class Square extends Rectangle { 
Square(double side) { 
super(side, side); 
} 


} 





注意 ， 上 述 层次 中 的 域 是 被 直接 访问 ， 而 不 是 通过 访问 方法 。 这 是 为 了 简洁 起 见 才 这 么 做 
的 ， 如 果 层 次 结构 是 公有 的 〈 见 第 14 条 ) ， 则 不 允许 这 样 做 。 


简 而 言 之 ， 标 签 类 很 少 有 适用 的 时 候 。 当 你 想 要 编写 一 个 包含 显 式 标签 域 的 类 时 ， 应 该 考 
虑 一 下 ， 这 个 标签 是 否 可 以 被 取消 ， 这 个 类 是 否 可 以 用 类 层次 来 代替 。 当 你 遇 到 一 个 包含 标 
签 域 的 现 有 类 时 ， 就 要 考虑 将 它 重 构 到 一 个 层次 结构 中 去 。 





有 些 语 言 支持 函数 指针 (function pointer), AZ (delegate), lambda Aik A (lambda 
expression) ， 或 者 支持 类 似 的 机 制 ， 允 许 程序 把 “调用 特殊 函数 的 能 力 ” 存 储 起 来 并 传递 这 
种 能 力 。 这 种 机 制 通常 用 于 允许 函数 的 调用 者 通过 传人 第 二 个 函数 ， 来 指定 自己 的 行为 。 例 
如 ，C 语 言 标 准 库 中 的 qsort 函 数 要 求 用 一 个 指向 comparator (比较 器 ) 函数 的 指针 作为 参数 ， 
它 用 这 个 函数 来 比较 待 排序 的 元 素 。 比 较 器 函数 有 两 个 参数 ， 都 是 指向 元 素 的 指针 。 如 果 第 
一 个 参数 所 指 的 元 素 小 于 第 二 个 参数 所 指 的 元 素 ， 则 返回 一 个 负 整 数 ， 如 果 两 个 元 素 相 等 则 
返回 零 ， 如 果 第 一 个 参数 所 指 的 元 素 大 于 第 二 个 参数 所 指 的 元 素 ， 则 返回 一 个 正 整 数 。 通 过 
传递 不 同 的 比较 器 函数 ， 就 可 以 获得 各 种 不 同 的 排列 顺序 。 这 正 是 策略 (Strategy) 模式 
[Gamma95, p.315] 的 一 个 例子 。 比 较 器 函数 代表 一 种 为 元 素 排序 的 策略 。 


Java 没 有 提供 函数 指针 ， 但 是 可 以 用 对 象 引用 实现 同样 的 功能 。 调 用 对 象 上 的 方法 通常 是 
执行 该 对 象 (that object) 上 的 某 项 操作 。 然 而 ， 我 们 也 可 能 定义 这 样 一 种 对 象 ， 它 的 方法 执 
行 其 他 对 象 (other objects) (这 些 对 象 被 显 式 传递 给 这 些 方法 ) 上 的 操作 。 如 果 一 个 类 仅仅 
导出 这 样 的 一 个 方法 ， 它 的 实例 实际 上 就 等 同 于 一 个 指向 该 方法 的 指针 。 这 样 的 实例 被 称 为 
函数 对 象 (function object), ján, SK PMA: 

class: StringLengthComparator { 

public int compare(String s1, String s2) { 


return sl.length() - s2.length(Q); 
} 


这 个 类 导出 一 个 带 两 个 字符 串 参数 的 方法 ， 如 果 第 一 个 字符 串 的 长 度 比 第 二 个 的 短 ， 则 返 
回 一 个 负 整数 ， 如 果 两 个 字符 串 的 长 度 相等 ， 则 返回 零 ， 如 果 第 一 个 字符 串 比 第 二 个 的 长 ， 
则 返回 一 个 正 整数 。 这 个 方法 是 一 个 比较 器 ， 它 根据 长 度 来 给 字符 串 排序 ， 而 不 是 根据 更 常 
用 的 字典 顺序 。 指 向 StringLengthComparator 对 象 的 引用 可 以 被 当 作 是 一 个 指向 该 比较 器 的 
“函数 指针 (function pointer)”， 可 以 在 任意 一 对 字符 串 上 被 调用 。 换 名 话说 ，StringLength 
Comparator 实 例 是 用 于 字符 串 比 较 操 作 的 具体 策略 (concrete strategy), 


作为 典型 的 具体 策略 类 ，StringLengthComparator 类 是 无 状态 的 (stateless): 它 没有 域 ， 
所 以 ， 这 个 类 的 所 有 实例 在 功能 上 都 是 相互 等 价 的 。 因 此 ， 它 作为 一 个 Singleton 是 非常 合适 
的 ， 可 以 节省 不 必要 的 对 象 创建 开销 ( 见 第 3 条 和 第 5 条 ): 


class StringLengthComparator { 
private StringLengthComparator() { } 
public static final StringLengthComparator 
INSTANCE = new StringLengthComparator() ; 
public int compare(String sl, String s2) { 
return sl.lengthQ - s2.lengthQ; 
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} 
} 


为 了 把 StringLengthComparator 实 例 传递 给 方法 ， 需 要 适当 的 参数 类 型 。 使 用 
StringLengthComparator 并 不 好 ， 因 为 客户 端 将 无 法 传递 任何 其 他 的 比较 策略 。 相 反 ， 我 们 需 
要 定义 一 个 Comparator 接 口 ， 并 修改 StringLengthComparator 来 实现 这 个 接 口 。 换 名 话说， 我 
们 在 设计 具体 的 策略 类 时 ， 还 需要 定义 一 个 策略 接口 (strategy interface), ， 如 下 所 示 ， 

// Strategy interface 


public interface Comparator<T> { 
public int. compare(T tl, T t2); 


Comparator 接 口 的 这 个 定义 碰巧 也 出 现在 java.util 包 中 ， 但 是 这 并 不 神奇 ， 你 自己 也 完全 
可 以 定义 它 。Comparator 接 口 是 泛 型 ( 见 第 26 条 ) 的 ， 因 此 它 适 合作 为 除 字符 串 之 外 的 其 他 
对 象 的 比较 器 。 它 的 compare 方 法 的 两 个 参数 类 型 为 T ( 它 正常 的 类 型 参数 )， 而 不 是 String。 
只 要 声明 前 面 所 示 的 StringLengthComparator 类 要 这 么 做 ， 就 可 以 用 它 实 现 Comparator 
<String> 接 口 ; 

class StringLengthComparator implements Comparator<String> { 


... // Class body is identical to the one shown above 
} 


具体 的 策略 类 往往 使 用 匿名 类 声明 ( 见 第 22 条 )。 焉 面 的 语句 根据 长 度 对 一 个 字符 串 数组 
进行 排序 : 
Arrays.sort(stringArray, new Comparator<String>() { 
public int compare(String sl, String s2) { 
return sl.length() - s2.length(); 


y; 


但 是 注意 ， 以 这 种 方式 使 用 匿名 类 时 ， 将 会 在 每 次 执行 调用 的 时 候 创建 一 个 新 的 实例 。 如 
果 它 被 重复 执行 ， 考 虑 将 函数 对 象 存储 到 一 个 私有 的 静态 final 域 里 ， 并 重用 它 。 这 样 做 的 另 
一 种 好 处 是 ， 可 以 为 这 个 函数 对 象 取 一 个 有 意义 的 域名 称 。 


因为 策略 接口 被 用 做 所 有 具体 策略 实例 的 类 型 ， 所 以 我 们 并 不 需要 为 了 导出 具体 策略 ， 而 
把 具体 策略 类 做 成 公有 的 。 相 反 , “宿主 类 (host class)” 还 可 以 导出 公有 的 静态 域 (或 者 静 
态 工厂 方法 ) ， 其 类 型 为 策略 接口 ， 具 体 的 策略 类 可 以 是 宿主 类 的 私有 人 嵌 套 类 。 下 面 的 例子 使 
用 静态 成 员 类 ， 而 不 是 匿名 类 ， 以 便 允 许 具 体 的 策略 类 实现 第 二 个 接口 Serializable， 


// Exporting a concrete strategy 
class Host { 
private static class StrLenCmp 
implements Comparator<String>, Serializable { 
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public int compare(String sl, String s2) { 
return sl.length() - s2.lengthQ); 


} 

// Returned comparator is serializable 

public static final Comparator<String> 
STRING_LENGTH_COMPARATOR = new StrLenCmp(); 


. // Bulk of class omitted 


String 类 利用 这 种 模式 ， 通 过 它 的 CASE_INSENSITIVE_ORDER 域 ， 导 出 一 个 不 区 分 大 
小 写 的 字符 串 比 较 器 。 


简 而 言 之 ， 函 数 指针 的 主要 用 途 就 是 实现 策略 (Strategy) 模式 。 为 了 在 Java 中 实现 这 种 
模式 ， 要 声明 一 个 接口 来 表示 该 策略 ， 并 且 为 每 个 具体 策略 声明 一 个 实现 了 该 接口 的 类 。 当 
一 个 具体 策略 只 被 使 用 一 次 时 ， 通 常 使 用 匿名 类 来 声明 和 实例 化 这 个 具体 策略 类 。 当 一 个 具 
体 策略 是 设计 用 来 重复 使 用 的 时 候 ， 它 的 类 通常 就 要 被 实现 为 和 有 的 静态 成 员 类 ， 并 通过 公 
有 的 静态 final 域 被 导出 ， 其 类 型 为 该 策略 接口 。 





HEX (nested class) 是 指 被 定义 在 另 一 个 类 的 内 部 的 类 。 媒 套 类 存在 的 目的 应 该 只 是 为 
它 的 外 围 类 (enclosing class) 提供 服务 。 如 果 婴 套 类 将 来 可 能 会 用 于 其 他 的 某 个 环境 中 ， 它 就 
应 该 是 顶层 类 (top-level class), BAAR: 静态 成 员 类 (static member class) 、 非 静态 成 
员 类 (nonstatic member class) 、 匿 名 类 (anonymous class) 和 局 部 类 (local class) 。 除 了 第 
一 种 之 外 ， 其 他 三 种 都 被 称 为 内 部 类 (inner class)。 本 条 目 将 告诉 你 什么 时 候 应 该 使 用 哪 种 嵌 
套 类 ， 以 及 这 样 做 的 原因 。 


静态 成 员 类 是 最 简单 的 一 种 戏 套 类 。 最 好 把 它 看 作 是 普通 的 类 ， 只 是 碰巧 被 声明 在 另 一 个 
类 的 内 部 而 已 ， 它 可 以 访问 外 围 类 的 所 有 成 员 ， 包 括 那些 声明 为 私有 的 成 员 。 静 态 成 员 类 是 
外 围 类 的 一 个 静态 成 员 ， 与 其 他 的 静态 成 员 一 样 ， 也 遵守 同样 的 可 访问 性 规则 。 如 果 它 被 声 
明 为 私有 的 ， 它 就 只 能 在 外 围 类 的 内 部 才 可 以 被 访问 ， 等 等 。 


静态 成 员 类 的 一 种 常见 用 法 是 作为 公有 的 辅助 类 ， 仅 当 与 它 的 外 部 类 一 起 使 用 时 才 有 意 
义 。 例 如 ， 考 虑 一 个 枚 举 ， 它 描述 了 计算 器 支持 的 各 种 操作 ( 见 第 30 条 )。Operation 枚 举 应 该 
是 Calculator 类 的 公有 静态 成 员 类 ， 然 后 ，Calculator 类 的 客户 端 就 可 以 用 诸如 Calculator. 
Operation.PLUS 和 Calculator.Operation.MINUS 这 样 的 名 称 来 引用 这 些 操作 。 


从 语法 上 讲 ， 静 态 成 员 类 和 非 静态 成 员 类 之 间 唯 一 的 区 别 是 ， 静 态 成 员 类 的 声明 中 包含 修 
饰 符 static。 尽 管 它们 的 语法 非常 相似 ， 但 是 这 两 种 能 套 类 有 很 大 的 不 同 。 非 静态 成 员 类 的 每 
个 实例 都 隐 含 着 与 外 围 类 的 一 个 外 围 实例 (enclosing instance) 相关 联 。 在 非 静态 成 员 类 的 
实例 方法 内 部 ， 可 以 调用 外 围 实 例 上 的 方法 ， 或 者 利用 修饰 过 的 this 构 造 获得 外 围 实 例 的 引用 
ULS,，15.8.4]。 如 果 符 套 类 的 实例 可 以 在 它 外 围 类 的 实例 之 外 独立 存在 ， 这 个 人 嵌 套 类 就 必须 是 
静态 成 员 类 : 在 没有 外 围 实例 的 情况 下 ， 要 想 创建 非 静 态 成 员 类 的 实例 是 不 可 能 的 。 


当 非 静态 成 员 类 的 实例 被 创建 的 时 候 ， 它 和 外 围 实例 之 间 的 关联 关系 也 随 之 被 建立 起 来 ， 
而 且 ， 这 种 关联 关系 以 后 不 能 被 修改 。 通 常情 况 下 ， 当 在 外 围 类 的 某 个 实例 方法 的 内 部 调用 
非 静态 成 员 类 的 构造 器 时 ， 这 种 关联 关系 被 自动 建立 起 来 。 使 用 表达 式 enclosingInstance. 
new MemberClass(args) 来 手工 建立 这 种 关联 关系 也 是 有 可 能 的 ， 但 是 很 少 使 用 。 正 如 你 所 预 
料 的 那样 ， 这 种 关联 关系 需要 消耗 非 静态 成 员 类 实例 的 空间 ， 并 且 增 加 了 构造 的 时 间 开 销 。 


非 静态 成 员 类 的 一 种 常见 用 法 是 定义 一 个 Adapter[Gamma95, p.139]， 它 允许 外 部 类 的 实 
例 被 看 作 是 另 一 个 不 相关 的 类 的 实例 。 例 如 ，Map 接 口 的 实现 往往 使 用 非 静态 成 员 类 来 实现 它 
们 的 集合 视图 (collection view) ， 这 些 集合 视图 是 由 Map 的 keySet、entrySet 和 Values 方 法 返 
回 的 。 同 样 地 ， 诸如 Set 和 List 这 种 集合 接口 的 实现 往往 也 使 用 非 静 态 成 员 类 来 实现 它们 的 和 迭 
代 器 (iterator): 


类 和 和 扒 口 + 


天 


// Typical use of a nonstatic member class 
public class MySet<E> extends AbstractSet<E> { 
// Bulk of the class omitted 
public Iterator<E> iterator() { 
return new MyIterator(); 
} 


private class Mylterator implements Iterator<E> { 


3 } 

如 果 声 明成 员 类 不 要 求 访问 外 围 实例 ， 就 要 始终 把 static 修 饰 符 放 在 它 的 声明 中 ， 使 它 成 
为 静态 成 员 类 ， 而 不 是 非 静态 成 员 类 。 如 果 省 略 了 static 修 饰 符 ， 则 每 个 实例 都 将 包含 一 个 额 
外 的 指向 外 围 对 象 的 引用 。 保 存 这 份 引用 要 消耗 时 间 和 空间 ， 并 且 会 导致 外 围 实例 在 符合 垃 
圾 回收 ( 见 第 6 条 ) 时 却 仍然 得 以 保留 。 如 果 在 没有 外 围 实例 的 情况 下 ， 也 需要 分 配 实例 ， 就 
不 能 使 用 非 静态 成 员 类 ， 因 为 非 静 态 成 员 类 的 实例 必须 要 有 一 个 外 围 实 例 。 


私有 静态 成 员 类 的 一 种 常见 用 法 是 用 来 代表 外 围 类 所 代表 的 对 象 的 组 件 。 例 如 ， 考 虑 一 个 
Map 实 例 ， 它 把 键 (key) 和 值 (value) 关联 起 来 。 许 多 Map 实 现 的 内 部 都 有 一 个 Entry 对 象 ， 
对 应 于 Map 中 的 每 个 键 - 值 对 。 虽 然 每 个 entry 都 与 一 个 Map 关 联 ,但 是 entry 上 的 方法 (getKey、 
getValue 和 setValue) 并 不 需要 访问 该 Map。 因 此 ， 使 用 非 静态 成 员 来 表示 entry 是 很 浪费 的 ， 
私有 的 静态 成 员 类 是 最 佳 的 选择 。 如 果 不 小 心 漏 掉 了 entry 声 明 中 的 static 修 饰 符 ， 该 Map 仍 然 
可 以 工作 ， 但 是 每 个 entry 中 将 会 包含 一 个 指向 该 Map 的 引用 ， 这 样 就 浪费 了 空间 和 时 间 。 


如 果 相 关 的 类 是 导出 类 的 公有 的 或 受 保护 的 成 员 ， 毫 无 疑问 ， 在 静态 和 非 静态 成 员 类 之 间 
做 出 正确 的 选择 是 非常 重要 的 。 在 这 种 情况 下 ， 该 成 员 类 就 是 导出 的 API 元 素 ， 在 后 续 的 发 行 
版 本 中 ， 如 果 不 违反 二 进 制 兼 容 性 ， 就 不 能 从 非 静 态 成 员 类 变 为 静态 成 员 类 。 


匿名 类 不 同 于 Java 程 序 设计 语言 中 的 其 他 任何 语法 单元 。 正 如 你 所 想像 的 ， 匿 名 类 没有 名 
字 。 它 不 是 外 围 类 的 一 个 成 员 。 它 并 不 与 其 他 的 成 员 一 起 被 声明 ， 而 是 在 使 用 的 同时 被 声明 
和 实例 化 。 匿 名 类 可 以 出 现在 代码 中 任何 允许 存在 表达 式 的 地 方 。 当 且 仅 当 匿名 类 出 现在 非 
静态 的 环境 中 时 ， 它 才 有 外 围 实 例 。 但 是 即使 它们 出 现在 静态 的 环境 中 ， 也 不 可 能 拥有 任何 
静态 成 员 。 


匿名 类 的 适用 性 受到 诸多 的 限制 。 除了 在 它们 被 声明 的 时 候 之 外 , 是 无 法 将 它们 实例 化 的 。 
你 不 能 执行 instanceof 测 试 ， 或 者 做 任何 需要 命名 类 的 其 他 事情 。 你 无 法 声明 一 个 匿名 类 来 实 
现 多 个 接口 ,或 者 扩展 一 个 类 , 并 同时 扩展 类 和 实现 接口 。 匿 名 类 的 客户 端 无 法 调用 任何 成 员 ， 
”除了 从 它 的 超 类 型 中 继承 得 到 之 外 。 由 于 匿名 类 出 现在 表达 式 当 中 ， 它 们 必须 保持 简短 一 一 大 
约 10 行 或 者 更 少 些 一 一 否则 会 影响 程序 的 可 读 性 。 


匿名 类 的 一 种 常见 用 法 是 动态 地 创建 函数 对 象 (function object， 见 第 21 条 ) 。 例 如 ， 第 
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92 页 中 的 sort 方 法 调用 , 利用 匿名 的 Comparator 实 例 ， 根 据 一 组 字符 串 的 长 度 对 它们 进行 排序 。 
匿名 类 的 另 一 种 常见 用 法 是 创建 过 程 对 象 (process object) ， 比 如 Runnable、Thread 或 者 
TimerTask 实 例 。 第 三 种 常见 的 用 法 是 在 静态 工厂 方法 的 内 部 (参见 第 18 条 中 的 intArrayAsList 
方法 ) 。 


局 部 类 是 四 种 嵌 套 类 中 用 得 最 少 的 类 。 在 任何 “可 以 声明 局 部 变量 ”的 地 方 ， 都 可 以 声明 
局 部 类 ， 并 且 局 部 类 也 遵守 同样 的 作用 域 规则 。 局 部 类 与 其 他 三 种 嵌 套 类 中 的 每 一 种 都 有 一 
些 共同 的 属性 。 与 成 员 类 一 样 ， 局 部 类 有 名 字 ， 可 以 被 重复 地 使 用 。 与 匿名 类 一 样 ， 只 有 当 
局 部 类 是 在 非 静态 环境 中 定义 的 时 候 ， 才 有 人 外围 实 例 ， 它 们 也 不 能 包含 静态 成 员 。 与 匿名 类 
一 样 ， 它 们 必须 非常 简短 ， 以 便 不 会 影响 到 可 读 性 。 


简 而 言 之 ， 共 有 四 种 不 同 的 伐 套 类 ， 每 一 种 都 有 自己 的 用 途 。 如 果 一 个 嵌 套 类 需要 在 单个 
方法 之 外 仍然 是 可 见 的 ， 或 者 它 太 长 了 ， 不 适合 于 放 在 方法 内 部 ， 就 应 该 使 用 成 员 类 。 如 果 
成 员 类 的 每 个 实例 都 需要 一 个 指向 其 外 围 实例 的 引用 ， 就 要 把 成 员 类 做 成 非 静态 的 ， 否 则 ， 
就 做 成 静态 的 。 假 设 这 个 嵌 套 类 属于 一 个 方法 的 内 部 ， 如 果 你 只 需要 在 一 个 地 方 创建 实例 ， 
并 且 已 经 有 了 一 个 预 置 的 类 型 可 以 说 明 这 个 类 的 特征 ， 就 要 把 它 做 成 匿名 类 ， 否 则 ， 就 做 成 


局 部 类 。 





第 5 章 
泛 型 


Java 1.5 发 行 版 本 中 增加 了 泛 型 (Generie) 。 在 没有 泛 型 之 前 ， 从 集合 中 读 取 到 的 每 一 
个 对 象 都 必须 进行 转换 。 如 果 有 人 不 小 心 插入 了 类 型 错误 的 对 象 ， 在 运行 时 的 转换 处 理 就 会 
出 错 。 有 了 证 型 之 后 ， 可 以 告诉 编译 器 每 个 集合 中 接受 哪些 对 象 类 型 。 编 译 器 自动 地 为 你 的 
插入 进行 转化 , .并 在 编译 时 告知 是 否 插入 了 类 型 错误 的 对 象 。 这 样 可 以 使 程序 既 更 加 安全 ， 
也 更 加 清楚 ， 但 是 要 享有 这 些 优势 有 一 定 的 难度 。 本 章 就 是 教 你 如 何 最 大 限度 地 享有 这 些 优 
势 ， 又 能 使 整个 过 程 尽 可 能 地 简单 化 。 有 关 这 部 分 内 容 的 详情 ， 请 参见 Langer 的 教程 
[Langer08]， 或 者 Naftalin 和 Wadler 合 著 的 书 [Naftalin07]。 





先 来 介绍 一 些 术 语 。 声明 中 具有 一 个 或 者 多 个 类 型 参数 (type parameter) 的 类 或 者 接口 ， 
就 是 泛 型 (generic) 类 或 者 接口 [JLS，8.1.2, 9.1.2]。 例 如 ， 从 Java 1.5 发 行 版 本 起 ，List 接 口 
就 只 有 单个 类 型 参数 E， 表 示 列 表 的 元 素 类 型 。 从 技术 的 角度 来 看 ， 这 个 接口 的 名 称 应 该 是 指 
现在 的 List<E> ( 读 作 “E 的 列表 ”), 但 是 人 们 经 常 把 它 简 称 为 List。 泛 型 类 和 接口 统称 为 泛 型 
(generic type) 。 


每 种 泛 型 定义 一 组 参数 化 的 类 型 (parameterized type)， 构 成 格式 为 :先是 类 或 者 接口 
的 名 称 ， 接 着 用 尖 括 号 (< >) 把 对 应 于 证 型 形式 类 型 参数 的 实际 类 型 参数 列表 [JLS ，4.4， 
4.5] 括 起 来 。 例 如 ，List<String> ( 读 作 “字符 串 列表 ”) 是 一 个 参数 化 的 类 型 ， 表 示 元 素 类 型 
为 String 的 列表 。(String 是 与 形式 类 型 参数 E 相 对 应 的 实际 类 型 参数 。) 


最 后 一 点 ， 每 个 泛 型 都 定义 一 个 原生 态 类 型 (raw type), ， 即 不 带 任何 实际 类 型 参数 的 泛 
型 名 称 [JLS，4.8]。 例 如 ， 与 List<E> 相 对 应 的 原生 态 类 型 是 List。 原 生态 类 型 就 像 从 类 型 声 
明 中 删除 了 所 有 证 型 信息 一 样 。 实 际 上 ， 原 生态 类 型 List 与 Java 平 台 没 有 泛 型 之 前 的 接口 类 型 
List 完 全 一 样 。 


~ 
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在 Java 1.5 版 本 发 行 之 前 ， 以 下 集合 声明 是 值得 参考 的 : 


// Now a raw collection type - don't do this! 


[ae 
* My stamp collection. Contains only Stamp instances. 
*/ ” 


private final Collection stamps = ... ; 


如 果 不 小 心 将 一 个 coin 放 进 了 stamp 集 合 中 ， 这 一 错误 的 插入 照样 得 以 编译 和 运行 并 且 不 
会 出 现任 何 错误 提示 : 


// Erroneous insertion of coin into stamp collection 
stamps.add(new Coin( . J 


直到 从 stamp 集 合 中 获取 coin 时 才 会 收 到 错误 提示 : 


// Now a raw iterator type - don't do this! 
for (Iterator i = stamps.iterator(); i. hasNext(); ) { 
eg s = (Stamp) i.next(); // Throws ClassCastException 
. // Do something with the stamp 
} 


就 如 本 书 中 经 常 提 到 的 ， 出 错 之 后 应 该 尽快 发 现 ， 最 好 是 编译 时 就 发 现 。 本 例 中 ， 直 到 运 
行 时 才 发 现 错误 ， 已 经 出 错 很 久 了 ， 而 且 你 在 代码 中 所 处 的 位 置 距离 包含 错误 的 这 部 分 代码 
已 经 很 远 了 。 一 旦 发 现 ClassCastException， 就 必须 搜索 代码 ， 查 找 将 coin 放 进 stamp 集 合 的 方 
法 调用 。 此 时 编译 器 帮 不 上 忙 ， 因 为 它 无 法 理解 这 种 注释 : “Contains only Stamp instances 
(只 包含 Stamp 实 例 )”。 


有 了 泛 型 ， 就 可 以 利用 改进 后 的 类 型 声明 来 代替 集合 中 的 这 种 注释 ， 告 诉 编译 器 之 前 的 注 
释 中 所 隐 含 的 信息 : 


// Parameterized collection type - typesafe 

private final Collection<Stamp> stamps = ... ; 

通过 这 条 声明 ， 编 译 器 知道 stamps 应 该 只 包含 Stamp 实 例 ， 并 给 予 保证 ， 假 设 整个 代码 是 
利用 Java 1.5 及 其 之 后 版 本 的 编译 器 进行 编译 的 ， 所 有 代码 在 编译 过 程 中 都 没有 发 出 (或 者 禁 
止 ， 请 见 第 24 条 ) 任何 警告 。 当 stamps 利 用 一 个 参数 化 的 类 型 进行 声明 时 ， 错 误 的 插入 会 产 
生 一 条 编译 时 的 错误 消息 ， 准 确 地 告诉 你 哪里 出 错 了 : 

Test.java:9: add(Stamp) in Collection<Stamp> cannot be applied 


to (Coin) 
stamps .add(new Coin()); 
A 


还 有 一 一 个 好 处 是 ， 从 集合 中 删除 元 素 时 不 再 需要 进行 手工 转换 了 。 编 译 器 会 蔡 你 插入 隐 
式 的 转换 ， 并 确保 它们 不 会 失败 (依然 假设 所 有 代码 都 是 通过 支持 泛 型 的 编译 器 进行 编译 的 ， 
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并 且 没有 产生 或 者 禁止 任何 警告 ) 。 无 论 你 是 否 使 用 for-each 循 环 ( 见 第 46 条 )， 上 述 功能 都 
适用 : 
// for-each loop over a parameterized collection - typesafe 


for (Stamp s : stamps) { // No cast 
... // Do something with the stamp 
} 


或 者 无 论 是 否 使 用 传统 的 for 循 环 也 一 样 : 


// for loop with parameterized iterator declaration - typesafe 
for (Iterator<Stamp> i = stamps.iterator(); i.hasNextQ); ) { 
Stamp s = i.next(); // No cast necessary 
... // Do something with the stamp 
} 


虽然 假设 不 小 心 将 coin 插 入 到 stamp 集 合 中 可 能 显得 有 点 牵强 ， 但 这 类 问题 却 是 真实 的 。 
例如 ， 很 容易 想像 有 人 会 不 小 心 将 一 个 java.util.Date 实 例 放 进 一 个 原本 只 包含 java.sql.Date 实 
例 的 集合 中 。 


如 上 所 述 ， 如 果 不 提供 类 型 参数 ， 使 用 集合 类 型 和 其 他 泛 型 也 仍然 是 合法 的 ， 但 是 不 应 该 
这 么 做 。 如 果 使 用 原生 态 类 型 ， 就 失掉 了 泛 型 在 安全 性 和 表述 性 方面 的 所 有 优势 。 既 然 不 应 
该 使 用 原生 态 类 型 ， 为 什么 Java 的 设计 者 还 要 允许 使 用 它们 呢 ? 这 是 为 了 提供 兼容 性 。 因 为 泛 
型 出 现 的 时 候 ，Java 平 台 即 将 进入 它 的 第 二 个 10 年 ， 已 经 存在 大 量 没有 使 用 泛 型 的 Java 代 码 。 
人 们 认为 让 所 有 这 些 代码 保持 合法 ， 并 且 能 够 与 使 用 泛 型 的 新 代码 互 用 ， 这 一 点 很 重要 。 它 
必须 合法 ， 才 能 将 参数 化 类 型 的 实例 传递 给 那些 被 设计 成 使 用 普通 类 型 的 方法 ， 反 之 亦 然 。 
这 种 需求 被 称 作 移植 兼容 性 (Migration Compatibility) ， 促 成 了 支持 原生 态 类 型 的 决定 。 


虽然 不 应 该 在 新 代码 中 使 用 像 List 这 样 的 原生 态 类 型 ， 使 用 参数 化 的 类 型 以 允许 插入 任意 
对 象 ， 如 List<Object>， 这 还 是 可 以 的 。 原生 态 类 型 List 和 参数 化 的 类 型 List<Object> 之 间 到 
底 有 什么 区 别 呢 ? 不 严格 地 说 ， 前 者 逃避 了 泛 型 检查 ， 后 者 则 明确 告知 编译 器 ， 它 能 够 持 有 
任意 类 型 的 对 象 。 虽然 你 可 以 将 List<String> 传 递 给 类 型 List 的 参数 ， 但 是 不 能 将 它 传 给 类 型 
List<Object> 的 参数 。 泛 型 有 子 类 型 化 (subtyping) 的 规则 ，List<String> 是 原生 态 类 型 List 
的 二 个 子 类 型 ， 而 不 是 参数 化 类 型 List<Object> 的 子 类 型 ( 见 第 25 条 )。 因 此 ， 如 果 使 用 像 
List 这 样 的 原生 态 类 型 ， 就 会 失掉 类 型 安全 性 ， 但 是 如 果 使 用 像 List<Object> 这 样 的 参数 化 类 
型 ， 则 不 会 。 á 


为 了 更 具体 地 进行 说 明 ， 请 参考 下 面 的 程序 : 


// Uses raw type (List) - fails at runtime! 

public static void main(String[] args) { 
List<String> strings = new ArrayList<String>(); 
unsafeAdd(strings, new Integer(42)); 
String s = strings.get(®); // Compiler-generated cast 
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} 


private static void unsafeAdd(List list, Object o) { 
list.add(o); i 


这 个 程序 可 以 进行 编译 但 是 因为 它 使 用 了 原生 态 类 型 List， 你 会 收 到 一 条 警告 : 


Test.java:10: warning: unchecked call to add(E) in raw type List 
list.add(o); 
A 


实际 上 ， 如 果 运 行 这 段 程序 ， 在 程序 试图 将 Strings.get(0) 的 调用 结果 转换 成 一 个 String 时 ， 
会 收 到 一 个 ClassCastException 异 常 。 这 是 一 个 编译 器 生成 的 转换 ， 因 此 一 般 保 证 会 成 功 ， 但 
是 我 们 在 这 个 例子 中 忽略 了 一 条 编译 器 警告 ， 就 会 为 此 而 付出 代价 。 


如 果 在 unsafeAdd 声 明 中 用 参数 化 类 型 List<Object> 代 替 原 生态 类 型 List， 并 试 着 重新 编译 
这 段 程序 ， 会 发 现 它 无 法 再 进行 编译 了 。 以 下 是 它 的 错误 消息 : 
Test.java:5: unsafeAdd(List<Object>,Object) cannot be applied 


to (List<String>, Integer) 
unsafeAdd(strings, new Integer(42)); 
A 


在 不 确定 或 者 不 在 乎 集合 中 的 元 素 类 型 的 情况 下 ， 你 也 许 会 使 用 原生 态 类 型 。 例 如 ， 假 设 
想 要 编写 一 个 方法 ， 它 有 两 个 集合 (set)， 并 从 中 返回 它们 共有 的 元 素 的 数量 。 如 果 你 对 泛 型 
还 不 熟悉 的 话 ， 可 以 参考 以 下 方式 来 编写 这 种 方法 : 
// Use of raw type for unknown element type - don't do this! 
static int numElementsInCommon(Set s1, Set s2) { 
int result = 0; 
for (Object ol : s1) 
if (s2.contains(ol)) 


result++; 
return result; 


这 个 方法 倒是 可 以 , 但 它 使 用 了 原生 态 类 型 ， 这 是 很 危险 的 。 从 Java 1.5 发 行 版 本 开始 ， 
Java 就 提供 了 一 种 安全 的 替代 方法 ， 称 作 无 限制 的 通配符 类 型 (unbounded wildcard type), 
如 果 要 使 用 泛 型 ， 但 不 确定 或 者 不 关心 实际 的 类 型 参数 ， 就 可 以 使 用 一 个 问号 代 圭 。 例 如 ， 
泛 型 Set<E> 的 无 限制 通配符 类 型 为 Set<?> ( 读 作 “ 某 个 类 型 的 集合 " ) 。 这 是 最 普通 的 参数 化 
Set 类 型 ， 可 以 持 有 任何 集合 。 下 面 是 numElementsInCommon 方 法 使 用 了 无 限制 通配符 类 型 时 
的 情形 : 

// Unbounded wildcard type - typesafe and flexible 

static int numElementsInCommon(Set<?> sl, Set<?> s2) { 


int result = 0; 
for (Object ol : s1) 
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if (s2.contains(o1)) 
result++; 
return result; 


在 无 限制 通 配 类 型 Set<?> 和 原生 态 类 型 Set 之 间 有 什么 区 别 呢 ? 这 个 问号 真正 起 到 作用 了 
吗 ? 这 一 点 不 需要 效 述 ， 但 通配符 娄 型 是 安全 的 ， 原 生态 类 型 则 不 安全 。 由 于 可 以 将 任何 元 
素 放 进 使 用 项 生态 类 型 的 集合 中 ,因此 很 容易 破坏 该 集合 的 类 型 约束 条 件 -( 如 第 100 页 的 例子 
中 所 示 的 unsafeAdd 方 法 )， 但 不 能 将 任何 元 素 (除了 null 之 外 ) 放 到 Collection<?> 中 。 如 果 
尝试 这 么 做 的 话 ， 将 会 产生 一 条 像 这 样 的 编译 时 错误 消息 : 

WildCard.java:13: cannot find symbol 

symbol : method add(String) 


location: interface Collection<capture#825 of ?> 
c.add("verboten") ; 
A 


这 样 的 错误 消息 显然 还 无 法 令 人 满意 ， 但 是 编译 器 已 经 尽 到 了 它 的 职责 ， 防 止 你 破坏 集合 
的 类 型 约束 条 件 。 你 不 仅 无 法 将 任何 元 素 (除了 null 之 外 ) 放 进 Collection<?> 中 ， 而 且 根本 无 
法 猜测 你 会 得 到 哪 种 类 型 的 对 象 。 要 是 无 法 接受 这 些 限 制 ， 就 可 以 使 用 泛 型 方法 (generic 
method， 见 第 27 条 ) 或 者 有 限制 的 通配符 类 型 (bounded wildcard type， 见 第 28 条 )。 


不 要 在 新 代码 中 使 用 原生 态 类 型 ， 这 条 规则 有 两 个 小 小 的 例外 ， 两 者 都 源 于 “ 泛 型 信息 可 
以 在 运行 时 被 擦 除 ”( 见 第 25 条 ) 这 一 事实 。 在 类 文字 (class literal) 中 必须 使 用 原生 态 类 型 。 
规范 不 允许 使 用 参数 化 类 型 (虽然 允许 数组 类 型 和 基本 类 型 ) [JLS，15.8.2]。 换 句 话 说 ， 
List.class，String[].class 和 int.class 都 合法 ， 但 是 List<String.class 和 List<?>.class 则 不 合法 。 


这 条 规则 的 第 二 个 例外 与 instanceof 操 作 符 有 关 。. 由 于 泛 型 信息 可 以 在 运行 时 被 擦 除 ， 因 
此 在 参数 化 类 型 而 非 无 限制 通配符 类 型 上 使 用 instanceof 操 作 符 是 非法 的 。 用 无 限制 通配符 类 
型 代替 原生 态 类 型 ， 对 instanceof 操 作 符 的 行为 不 会 产生 任何 影响 。 在 这 种 情况 下 ， 尖 括号 
(<>) 和 问号 (? ) 就 显得 多 余 了 。 下 面 是 利用 泛 型 来 使 用 instanceof 操 作 符 的 首选 方法 : 


// Legitimate use of raw type - instanceof operator 
if (o instanceof Set) { // Raw type 
Set<?> m = (Set<?>) o; // Wildcard type 


} 


注意 ， 一 旦 确定 这 个 o 是 个 Set， 就 必须 将 它 转换 成 通配符 类 型 Set<?>， 而 不 是 转换 成 原生 
态 类 型 Set。 这 是 个 受 检 的 (checked) 转换 ， 因 此 不 会 导致 编译 时 警告 。 


总 之 ， 使 用 原生 态 类 型 会 在 运行 时 导致 异常 ， 因 此 不 要 在 新 代码 中 使 用 。 原 生态 类 型 只 是 
为 了 与 引入 泛 型 之 前 的 遗留 代码 进行 兼容 和 互 用 而 提供 的 。 让 我 们 做 个 快速 的 回顾 : 
Set<Object> 是 个 参数 化 类 型 ， 表 示 可 以 包含 任何 对 象 类 型 的 一 个 集合 ，Set<?> 则 是 一 个 通 配 
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符 类 型 ， 表 示 只 能 包含 某 种 未 知 对 象 类 型 的 一 个 集合 ，Set 则 是 个 原生 态 类 型 ， 它 脱离 了 泛 型 
系统 。 前 两 种 是 安全 的 ， 最 后 一 种 不 安全 。 


. 为 便于 参考 ， 表 5-1 概 括 了 本 条 目 中 所 介绍 的 术语 (及 本 章 其 他 条 目 中 介绍 的 一 些 术语 ): 


表 5-1 本 章 条 目 中 所 介绍 的 术语 





术语 


参数 化 的 类 型 
实际 类 型 参数 
泛 型 
形式 类 型 参数 

无 限制 通配符 类 型 
原生 态 类 型 

有 限制 类 型 参数 
递归 类 型 限制 

有 限制 通配符 类 型 
泛 型 方法 
”类 型 令 牌 


示 A 
List<String> 
String 
List<E> 
E 
List<?> 
List 
<E extends Number> 
<T extends Comparable<T>> 
List<? extends Number> 
static <E> List<E> asList(E[] a) 
String.class 


所 在 条 目 


第 23 条 
第 23 条 
第 23，26 条 
第 23 条 
第 23 条 
第 23 条 
第 26 条 
第 27 条 
第 28 条 
第 27 条 
第 29 条 
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用 泛 型 编程 时 ， 会 遇 到 许多 编译 器 警告 : 非 受 检 强 制 转 化 警告 (unchecked cast warnings), 
非 受 检 方 法 调用 警告 、 非 受 检 普 通 数组 创建 警告 ， 以 及 非 受 检 转 换 警告 (unchecked conversion 
warnings) 。 当 你 越 来 越 熟悉 证 型 之 后 ， 遇 到 的 警告 也 会 越 来 越 少 ， 但 是 不 要 期 待 从 一 开始 用 
泛 型 编写 代码 就 可 以 正确 地 进行 编译 。 


有 许多 非 受 检 警 告 很 容易 消除 。 例 如 ， 假 设 意外 地 编写 了 这 样 一 个 声明 ， 
Set<Lark> exaltation = new HashSet(); 

编译 器 会 细致 地 提醒 你 哪里 出 错 了 : 

Venery.java:4: warning: [unchecked] unchecked conversion 


found : HashSet, required: Set<Lark> 
Set<Lark> exaltation = new HashSet(); 


你 就 可 以 纠正 所 显示 的 错误 ， 消 除 警告 : 


Set<Lark> exaltation = new HashSet<Lark>(); 


有 些 警告 比较 难以 消除 。 本 章 主 要 介绍 这 种 警告 的 示例 。 当 你 遇 到 需要 进行 一 番 思 考 的 警 
告 时 ， 要 坚持 住 ! 要 尽 可 能 地 消除 每 一 个 非 受 检 警 告 。 如 果 消 除了 所 有 警告 ,就 可 以 确保 代 
码 是 类 型 安全 的 ， 这 是 一 件 很 好 的 事情 。 这 意味 着 不 会 在 运行 时 出 现 ClassCastException 异 常 ， 
你 会 更 加 自信 自己 的 程序 可 以 实现 预期 的 功能 。 


如 果 无 法 消除 警告 ， 同 时 可 以 证 明 引 起 警告 的 代码 是 类 型 安全 的 ，( 只 有 在 这 种 情况 下 才 ) 
可 以 用 一 个 @SuppressWarnings ("unchecked") 注 解 来 禁止 这 条 警告 。 如 果 在 禁止 警告 之 前 
没有 先 证 实 代 码 是 类 型 安全 的 ， 那 就 只 是 给 你 自己 一 种 错误 的 安全 感 而 已 。 代 码 在 编译 的 时 
候 可 能 没有 出 现任 何 警告 ， 但 它 在 运行 时 仍然 会 抛 出 ClassCastException 异 常 。 但 是 如 果 忽 略 
(而 不 是 禁止 ) 明知 道 是 安全 的 非 受 检 警 告 ， 那 么 当 新 出 现 一 条 真正 有 问题 的 警告 时 ， 你 也 不 
会 注意 到 。 新 出 现 的 警告 就 会 淹没 在 所 有 的 错误 警告 当中 。 


SuppressWarnings 注 解 可 以 用 在 任何 粒度 的 级 别 中 ， 从 单独 的 局 部 变量 声明 到 整个 类 都 
可 以 。 应 该 始终 在 尽 可 能 小 的 范围 中 使 用 SuppressWarnings 注 解 。 它 通常 是 个 变量 声明 ， 或 
是 非常 简短 的 方法 或 者 构造 器 。 永 远 不 要 在 整个 类 上 使 用 SuppressWarnings， 这 么 做 可 能 会 
掩盖 了 重要 的 警告 。 


如 果 你 发 现 自 己 在 长 度 不 止 一 行 的 方法 或 者 构造 器 中 使 用 了 SuppressWarnings 注 解 ， 可 
以 将 它 移 到 一 个 局 部 变量 的 声明 中 。 虽 然 你 必须 声明 一 个 新 的 局 部 变量 ， 不 过 这 么 做 还 是 值 
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得 的 。 例如 ， 考虑 ArrayList 类 当中 的 toArray 方 法 : 


public <T> T[] toArray(T[] a) { 
if (a.length < size) 
return (T[]) Arrays.copyOf(elements, size, a.getClass()); 
System.arraycopy(elements, 0, a, 0, size); 
if (a.length > size) 
a[size] = null; 
return a; 


} 
如 果 编 译 ArrayList， 该 方法 就 会 产生 成 这 条 警告 ; 


ArrayList. java:305: warning: [unchecked] unchecked cast 
found : 0bject[] required: T[] 
return (T[]) Arrays.copyOf(elements, size, a.getClass()); 
A 


将 SuppressWarnings 注 解放 在 return 语 揣 中 是 非法 的 ， 因 为 它 不 是 一 个 声明 [JLS,9.7]。 
你 可 以 试 着 将 注解 放 在 整个 方法 上 ， 但 是 在 实践 中 千 万 不 要 这 么 做 ， 而 是 应 该 声明 一 个 局 部 
变量 来 保存 返回 值 ， 并 注解 其 声明 ， 像 这 样 : 


// Adding local variable to reduce scope of @SuppressWarnings 
public <T> T[] toArray(T[] a) { 
if (a.length < size) { 
// This cast is correct because the array we're creating 
// is of the same type as the one passed in, which is T[]. 
@SuppressWarnings("unchecked") T[] result = 
(T[]) Arrays.copyOf(elements, size, a.getClass()); 
return result; 


System.arraycopy(elements, 0, a, 0, size); 
if (a.length > size) 

a[size] = null; 
return a; 


} 
这 个 方法 可 以 正确 地 编译 ， 禁止 非 受 检 警告 的 范围 也 减 到 了 最 小 。 


每 当 使 用 SuppressWarnings ("unchecked") 注 解 时 ， 都 要 添加 一 条 注释 ， 说 明 为 什么 这 
么 做 是 安全 的 。 这 样 可 以 帮助 其 他 人 理解 代码 ， 更 重要 的 是 ， 可 以 尽量 减少 其 他 人 修改 代码 
后 导致 计算 不 安全 的 概率 。 如 果 你 觉得 这 种 注释 很 难 编写 ， 就 要 多 加 思考 。 最 终 你 会 发 现 非 
受 检 操 作 是 非常 不 安全 的 。 


总 而 言 之 ， 非 受 检 警 告 很 重要 ， 不 要 忽略 它们 。 每 一 条 警告 都 表示 可 能 在 运行 时 抛 出 
ClassCastException 异 常 。 要 尽 最 大 的 努力 消除 这 些 警 告 。 如 果 无 法 消除 非 受 检 警 告 ， 同 时 可 
以 证 明 引 起 警告 的 代码 是 类 型 安全 的 ， 就 可 以 在 尽 可 能 小 的 范围 中 ， 用 @SuppressWarnings 
("unchecked") 注 解禁 止 该 警告 。 要 用 注释 把 禁止 该 警告 的 原因 记录 下 来 。 





数组 与 泛 型 相 比 ， 有 两 个 重要 的 不 同 点 。 首 先 ， 数 组 是 协 变 的 (covariant) 。 这 个 词 听 起 
来 有 点 吓人 ， 其 实 只 是 表示 如 果 Sub 为 Super 的 子 类 型 ， 那 么 数组 类 型 Sub[] 就 是 Super[] 的 子 类 
型 。 相 反 ， 泛 型 则 是 不 可 变 的 (invariant): 对 于 任意 两 个 不 同 的 类 型 Type1 和 Type2，List 
<Typel> 既 不 是 List<Type2> 的 子 类 型 ， 也 不 是 List<Type2> 的 超 类 型 [JILS，4.10，Naftalin07 ， 
2.5]。 你 可 能 认为 ， 这 意味 着 泛 型 是 有 缺陷 的 ， 但 实际 上 可 以 说 数组 才 是 有 缺陷 的 。 


下 面 的 代码 片段 是 合法 的 : 


// Fails at runtime! 
Object[] objectArray = new Long[1]; 
objectArray[@] = "I don't fit in"; // Throws ArrayStoreException 


但 下 面 这 段 代 码 则 不 合法 : 


// Won't compile! 

List<Object> ol = new ArrayList<Long>(); // Incompatible types 

ol.add("I don't fit in"); 

这 其 中 无 论 哪 种 方法 ， 都 不 能 将 String 放 进 Long 容 器 中 ， 但 是 利用 数组 ， 你 会 在 运行 时 发 
现 所 犯 的 错误 ， 利 用 列表 ， 则 可 以 在 编译 时 发 现 错误 。 我 们 当然 希望 在 编译 时 发 现 错误 了 。 


数组 与 泛 型 之 间 的 第 二 大 区 别 在 于 ， 数 组 是 具体 化 的 (reified) [JILS，4.7]。 因 此 数组 会 
在 运行 时 才 知 道 并 检查 它们 的 元 素 类 型 约束 。 如 上 所 述 , 如 果 企 图 将 String 保 存 到 Long 数 组 中 ， 
就 会 得 到 一 个 ArrayStoreException 异 常 。 相 比 之 下 ， 泛 型 则 是 通过 擦 除 (erasure) [JLS, 4.6] 
来 实现 的 。 因 此 泛 型 只 在 编译 时 强化 它们 的 类 型 信息 ， 并 在 运行 时 丢弃 (或 者 擦 除 ) 它们 的 
元 素 类 型 信息 。 擦 除 就 是 使 泛 型 可 以 与 没有 使 用 泛 型 的 代码 随意 进行 互 用 ( 见 第 23 条 )。 


由 于 上 述 这 些 根本 的 区 别 ， 因 此 数组 和 泛 型 不 能 很 好 地 混合 使 用 。 例 如 ， 创 建 泛 型 、 参 数 
化 类 型 或 者 类 型 参数 的 数组 是 非法 的 。 这 些 数 组 创建 表达 式 没有 一 个 是 合法 的 : new 
List<E>[]、new List<String>[] 和 new E[]。 这 些 在 编译 时 都 会 导致 一 个 generic array creation 
( 泛 型 数组 创建 ) 错误 。 


为 什么 创建 泛 型 数组 是 非法 的 ? 因为 它 不 是 类 型 安全 的 。 要 是 它 合 法 ， 编 译 器 在 其 他 正确 
的 程序 中 发 生 的 转换 就 会 在 运行 时 失败 ， 并 出 现 一 个 ClassCastException 异 常 。 这 就 违背 了 
泛 型 系统 提供 的 基本 保证 。 


为 了 更 具体 地 对 此 进行 说 明 ， 考 虑 以 下 代码 片断 : 


// Why generic array creation is illegal - won't compile! 
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List<String>[] stringLists = new List<String>[1]; // @) 


List<Integer> intList = Arrays.asList(42); // (2) 
Object[] objects = stringLists; // B) 
objects[@] = intList; i // (4) 
String s = stringLists[0] .get(0) ; // (5) 


我 们 假设 第 1 行 是 合法 的 ， 它 创建 了 一 个 泛 型 数组 。 第 2 行 创建 并 初始 化 了 一 个 包含 单个 
元 素 的 List<Integer>。 第 3 行将 List<String> 数 组 保存 到 一 个 Object 数 组 变量 中 ， 这 是 合法 的 ， 
因为 数组 是 协 变 的 。 第 4 行将 List<Integer> 保 存 到 Object 数组 里 唯一 的 元 素 中 ， 这 是 可 以 的 ， 
因为 泛 型 是 通过 擦 除 实现 的 : List<Integer> 实 例 的 运行 时 类 型 只 是 List， List<String>[] 实 例 的 
运行 时 类 型 则 是 List[] ， 因 此 这 种 安排 不 会 产生 ArrayStoreException 异 常 。 但 现在 我 们 有 麻烦 
了 。 我 们 将 一 个 List<Integer> 实 例 保存 到 了 原本 声明 只 包含 List<String> 实 例 的 数组 中 。 在 第 5 
行 中 ， 我 们 从 这 个 数组 里 唯一 的 列表 中 获取 了 唯一 的 元 素 。 编 译 器 自动 地 将 获取 到 的 元 素 转 
换 成 String， 但 它 是 一 个 Integer， 因 此 ， 我 们 在 运行 时 得 到 了 一 个 ClassCastException 异 常 。 
为 了 防止 出 现 这 种 情况 ，( 创 建 泛 型 数组 的 ) 第 1 行 产生 了 一 个 编译 时 错误 。 


从 技术 的 角度 来 说 ， 像 E、List<E> 和 List<String> 这 样 的 类 型 应 称 作 不 可 具体 化 的 (non- 
reifiable) 类 型 [JLS，4.7]。 直 观 地 说 ,不 可 具体 化 的 (non-reifiable) 类 型 是 指 其 运行 时 表示 
法 包含 的 信息 比 它 的 编译 时 表示 法 包含 的 信息 更 少 的 类 型 。 唯 一 可 具体 化 的 (reifiable) 参数 
化 类 型 是 无 限制 的 通配符 类 型 ， 如 List<?> 和 Map<?,?> ( 见 第 23 条 ) 。 虽 然 不 常用 ， 但 是 创建 
无 限制 通 配 类 型 的 数组 是 合法 的 。 


禁止 创建 泛 型 数组 可 能 有 点 讨厌 。 例 如 ， 这 表明 泛 型 一 般 不 可 能 返回 它 的 元 素 类 型 数组 
(部 分 解决 方案 请 见 第 29 条 ) 。 这 也 意味 着 在 结合 使 用 可 变 参 数 (varargs) 方法 ( 见 第 42 条 ) 
和 泛 型 时 会 出 现 令 人 费解 的 警告 。 这 是 由 于 每 当 调用 可 变 参数 方法 时 ， 就 会 创建 一 个 数组 来 
存放 varargs 参 数 。 如 果 这 个 数组 的 元 素 类 型 不 是 可 具体 化 的 (reifialbe) ， 就 会 得 到 一 条 警告 。 
关于 这 些 警 告 ， 除 了 把 它们 禁止 ( 见 第 24 条 ) ， 并 且 避 免 在 API 中 混合 使 用 泛 型 与 可 变 参 数 之 
外 ， 别 无 他 法 。 


当 你 得 到 泛 型 数组 创建 错误 时 ， 最 好 的 解决 办 法 通常 是 优先 使 用 集合 类 型 List<E>， 而 不 是 数 
组 类 型 E[]。 这 样 可 能 会 损失 一 些 性 能 或 者 简洁 性 ， 但 是 换 回 的 却 是 更 高 的 类 型 安全 性 和 互 用 性 。 


例如 ,假设 有 一 个 (Collections.synchronizedList 返 回 的 那 种 ) 同步 列表 和 一 个 函数 ( 它 
有 了 两 了 与 该 列表 的 元 素 同 类 型 的 参数 值 ， 并 返回 第 三 个 值 ) 。 现 在 假设 要 编写 一 个 方法 reduce， 
并 使 用 函数 apply 来 处 理 这 个 列表 。 假 设 列表 元 素 类 型 为 整数 ， 并 且 函 数 是 用 来 做 两 个 整数 的 
求 和 运算 , reduce 方 法 就 会 返回 列表 中 所 有 值 的 总 和 。 如果 函数 是 用 来 做 两 个 整数 求 积 的 运算 ， 
该 方法 就 会 返回 列表 中 值 的 乘积 。 如 果 列 表 包 含 字符 串 ， 并 且 函 数 连接 两 个 字符 串 ， 该 方法 
就 会 返回 一 个 字符 串 ， 它 按 顺 序 包含 了 列表 中 的 所 有 字符 串 。 除 了 列表 和 函数 之 外 ，reduce 方 
法 还 采用 初始 值 进行 减法 运算 ， 列 表 为 空 时 会 返回 这 个 初始 值 。( 初 始 值 一 般 为 函数 的 识别 元 
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素 ， 加 法 为 0， 乘 法 为 1， 字 符 串 连接 时 是 "。) 以 下 是 没有 泛 型 时 的 代码 : 


// Reduction without generics, and with concurrency flaw! 
static Object reduce(List list, Function f, Object initVal) { 
synchronized(list) { 
Object result = initVal; 
for (Object o : list) 
result = f.apply(result, 0); 
return result; 


} 


interface Function { 
Object apply(Object argl, Object arg2); 


假设 你 现在 已 经 读 过 第 67 条 ， 它 告诉 你 不 要 从 同步 区 域 中 调用 “外 来 的 (alien) 方法 ”。 
因此 ， 在 持 有 锁 的 时 候 修改 reduce 方 法 来 复制 列表 中 内 容 ， 也 可 以 让 你 在 备份 上 执行 减法 。 
Java 1.5 发 行 版 本 之 前 ， 要 这 么 做 一 般 是 利用 List 的 toArray 方 法 〈 它 在 内 部 锁定 列表 ) : 


// Reduction without generics or concurrency flaw 
static Object reduce(List list, Function f, Object initVal) { 
Object[] snapshot = list.toArray(); // Locks list internally 
Object result = initVal; 
for (E e: snapshot) 
result = f.apply(result, e); 
return result; 


} 


如 果 试 图 通过 证 型 来 完成 这 一 点 ， 就 会 遇 到 我 们 之 前 讨论 过 的 那 种 麻烦 。 以 下 是 Function 
接口 的 泛 型 版 : 


interface Function<T> { 
T apply(T argl, T arg2); 


下 面 是 一 种 天 真 的 尝试 ， 试 图 将 泛 型 应 用 到 修改 过 的 reduce 方 法 。 这 是 一 个 泛 型 方法 
(generic method， 见 第 27 条 )。 如 果 你 不 理解 这 条 声明 ， 也 不 必 担 心 。 对 于 这 个 条 目 来 说 ， 应 
该 把 注意 力 集中 在 方法 体 上 : 


// Naive generic version of reduction - won't compile! 
static <E> E reduce(List<E> list, Function<E> f, E initVal) { 
E[] snapshot = list.toArray(); // Locks list 
E result = initVal; 
for (E e : snapshot) 
result = f.apply(result, e); 
return result; 


} 


如 果 试 着 编译 这 个 方法 ， 就 会 得 到 下 面 的 错误 消息 : 


Reduce.java:12: incompatible types 
found : Object{], required: E[] 
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E[] snapshot = list.toArray(); // Locks list 
A 


你 会 说 ， 这 没什么 大 不 了 的 ， 我 会 将 Object 数组 转换 成 一 个 E 数 组 : 
E[] snapshot = (E[]) list.toArray(); 


它 是 消除 了 那 条 错误 ， 但 是 现在 得 到 了 一 条 警告 ; 


Reduce.java:12: warning: [unchecked] unchecked cast 
found : Object[], required: E[] 
E[] snapshot = (E[]) list.toArray(); // Locks list 
A 


编译 器 告诉 你 ， 它 无 法 在 运行 时 检查 转换 的 安全 性 ， 因为 它 在 运行 时 还 不 知道 E 是 什么 一 一 
记 住 ， 元素 类 型 信息 会 在 运行 时 从 泛 型 中 被 擦 除 。 这 段 程 序 可 以 运行 四 ?结果 表明 ， 它 可 以 
运行 ， 但 是 不 安全 。 通 过 微小 的 修改 ， 就 可 以 让 它 在 没有 包含 显 式 转换 的 行 上 抛 出 
ClassCastException 异 常 。 snapshot 的 编译 时 类 型 为 E[]， 它 可 以 为 String[]、Integer[] 或 者 任 
何其 他 种 类 的 数组 。 运 行 时 类 型 为 Object[]， 这 是 很 危险 的 。 不 可 具体 化 的 类 型 的 数组 转换 只 
能 在 特殊 情况 下 使 用 〈 见 第 26 条 ) 。 


那么 应 该 做 些 什么 呢 ? 用 列表 代替 数组 。 下 面 的 reduce 方 法 编译 时 就 没有 任何 错误 或 者 
敖 告 
// List-based generic reduction 
static <E> E reduce(List<E> list, Function<E> f, E initVal) { 
List<E> snapshot; 
synchronized(list) { 
snapshot = new ArrayList<E>(list); 
E result = initVal; 
for (E e : snapshot) 
result = f.apply(result, e); 
return result; 


} 


这 个 版 本 的 代码 比 数组 版 的 代码 稍微 元 长 一 点 ， 但 是 可 以 确定 在 运行 时 不 会 得 到 
ClassCastException 异 常 ， 为 此 也 值 了 。 


总 而 言 之 ， 数 组 和 泛 型 有 着 非常 不 同 的 类 型 规则 。 数 组 是 协 变 且 可 以 具体 化 的 ， 泛 型 是 不 
可 变 的 且 可 以 被 擦 除 的 。 因 此 ， 数 组 提供 了 运行 时 的 类 型 安全 ， 但 是 没有 编译 时 的 类 型 安全 ， 
反之 ， 对 于 泛 型 也 一 样 。 一 般 来 说 ， 数 组 和 泛 型 不 能 很 好 地 混合 使 用 。 如 果 你 发 现 自己 将 它 
们 混合 起 来 使 用 ， 并 且 得 到 了 编译 时 错误 或 者 警告 ， 你 的 第 一 反应 就 应 该 是 用 列表 代替 数组 。 





一 般 来 说 , 将 集合 声明 参数 化 ,以 及 使 用 JDK 所 提供 的 泛 型 和 泛 型 方法 , 这 些 都 不 太 困 难 。 
编写 自己 的 泛 型 会 比较 困难 一 些 ， 但 是 值得 花 些 时 间 去 学 习 如 何 编写 。 


考虑 第 6 条 中 这 个 简单 的 堆栈 实现 ， 


// Object-based collection - a prime candidate for generics 
public class Stack { 


private Object[] elements; 
private int size = 0; 
private static final int DEFAULT_INITIAL_CAPACITY = 16; 


public Stack() { 
elements = new Object (DEFAULT_INITIAL_CAPACITY]; 


} 

public void push(Object e) { 
ensureCapacity(); 
elements[size++] = e; 

} 


public Object pop() { 
if (size == @) 
throw new EmptyStackException(); 
Object result = elements[--size]; 
elements[size] = null; // Eliminate obsolete reference 
return result; 


} 


public boolean isEmpty() { 
return size == 0; 


private void ensureCapacity() { 
if (elements.length == size) 
elements = Arrays.copyOf(elements, 2 * size + 1); 


} 


这 个 类 是 泛 型 化 (generification) 的 主要 备 选 对 象 ， 换 句 话 说， 可 以 适当 地 强化 这 个 类 来 


利用 泛 型 。 根 据 实际 情况 来 看 ， 必 须 转换 从 堆栈 里 弹出 的 对 象 ， 以 及 可 能 在 运行 时 失败 的 那 
些 转换 。 将 类 泛 型 化 的 第 一 个 步骤 是 给 它 的 声明 添加 一 个 或 者 多 个 类 型 参数 。 在 这 个 例子 中 
有 一 个 类 型 参数 ， 它 表示 堆栈 的 元 素 类 型 ， 这 个 参数 的 名 称 通 常 为 E (MBAR). 


下 一 步 是 用 相应 的 类 型 参数 替换 所 有 的 Object 类 型 ， 然 后 试 着 编译 最 终 的 程序 : 


// Initial attempt to generify Stack = won't compile! 
public class Stack<E> { 


private E[] elements; 
private int size = 0; 
private static final int DEFAULT_INITIAL_CAPACITY = 16; 


public StackQ { 
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elements = new E[DEFAULT_INITIAL_CAPACITY] ; 


public void push(E e) { 
ensureCapacity(); 
elements[size++] = e; 
} 
public E pop() { 
if (size==0) 
throw new EmptyStackException(); 
E result = elements[--size]; 
elements(size] = null; // Eliminate obsolete reference 
return result; 


.. // no changes in isEmpty or ensureCapacity 
} 


通常 ， 你 将 至 少 得 到 一 个 错误 或 警告 ， 这 个 类 也 不 例外 。 幸 运 的 是 ， 这 个 类 只 产生 一 个 错 
ik, 如 下 : 
Stack.java:8: generic array creation 


elements = new E[DEFAULT_INITIAL_CAPACITY] ; 
A 


如 第 25 条 中 所 述 ， 你 不 能 创建 不 可 具体 化 的 (non-reifiable) 类 型 的 数组 ， 如 E。 每 当 编 
写 用 数组 支持 的 泛 型 时 ， 都 会 出 现 这 个 问题 。 解 决 这 个 问题 有 两 种 方法 。 第 一 种 ， 直 接线 过 
创建 泛 型 数组 的 禁令 : 创建 一 个 Object 的 数组 ， 并 将 它 转换 成 泛 型 数组 类 型 。 现 在 错误 是 消除 
T, 但 是 编译 器 会 产生 一 条 警告 。 这 种 用 法 是 合法 的 ,但 (整体 上 而 言 ) 不 是 类 型 安全 的 : 
Stack.java:8: warning: [unchecked] unchecked cast 


found : Object[], required: E[] 
elements = (E[]) new Object [DEFAULT_INITIAL_CAPACITY] ; 
A 


编译 器 不 可 能 证 明 你 的 程序 是 类 型 安全 的 ， 但 是 你 可 以 证 明 。 你 自己 必须 确保 未 受 检 的 转 
换 不 会 危及 到 程序 的 类 型 安全 性 。 相 关 的 数组 ( 即 elements 变 量 ) 保存 在 一 个 私有 的 域 中 ， 永 
远 不 会 被 返回 到 客户 端 ， 或 者 传 给 任何 其 他 方法 。 这 个 数组 中 保存 的 唯一 元 素 ， 是 传 给 push 
方法 的 那些 元 素 ， 它 们 的 类 型 为 E， 因 此 未 受 检 的 转换 不 会 有 任何 危害 。 


一 旦 你 证 明了 未 受 检 的 转换 是 安全 的 ， 就 要 在 尽 可 能 小 的 范围 中 禁止 敬告 ( 见 第 24 条 )。 
在 这 种 情况 下 ， 构 造 器 只 包含 未 受 检 的 数组 创建 ， 因 此 可 以 在 整个 构造 器 中 禁止 这 条 警告 。 
通过 增加 一 条 注解 来 完成 禁止 ，Stack 能 够 正确 无 误 地 进行 编译 ， 你 就 可 以 使 用 它 了 ， 无 需 显 
式 的 转换 ， 也 无 需 担 心 会 出 现 ClassCastException 异 常 : 

// The elements array will contain only E instances from push(E). 

// This is sufficient to ensure type safety, but the runtime 

// type of the array won't be E[]; it will always be Object[]! 


@SuppressWarnings ("unchecked") 
public StackQ) { 
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elements = (E[]) new Object[DEFAULT_INITIAL_CAPACITY]; 


消除 Stack 中 泛 型 数组 创建 错误 的 第 二 种 方法 是 ， 将 elements 域 的 类 型 从 E[] 改 为 Object[]。 
这 么 做 会 得 到 一 条 不 同 的 错误 : 
Stack.java:19: incompatible types 


found : Object, required: E 
E result = elements[--size]; 
A 


通过 把 从 数组 中 获取 到 的 元 素 由 Object 转换 成 E， 可 以 将 这 条 错误 变 成 一 条 警告 : 


Stack.java:19: warning: [unchecked] unchecked cast 
found : Object, required: E 
E result = (E) elements[--size]; 
A 


由 于 E 是 一 个 不 可 具体 化 的 (non-reifiable) 类 型 ， 编译 器 无 法 在 运行 时 检验 转换 。 你 还 
是 可 以 自己 证 实 未 受 检 的 转换 是 安全 的 ， 因 此 可 以 禁止 该 警告 。 根 据 第 24 条 的 建议 ， 我 们 只 
要 在 包含 未 受 检 转 换 的 任务 上 禁止 警告 ， 而 不 是 在 整个 pop 方 法 上 就 可 以 了 ， 如 下 : 


// Appropriate suppression of unchecked warning 
public E pop() { 
if (size==0) 
throw new EmptyStackException(); 
// push requires elements to be of type E, so cast is correct 
@SuppressWarnings("unchecked") E result = 
(E) elements[--size]; 
elements[size] = null; // Eliminate obsolete reference 
return result; 


} 


具体 选择 这 两 种 方法 中 的 哪 一 种 来 处 理 泛 型 数组 创建 错误 ， 则 主要 看 个 人 的 偏好 了 。 所 有 
其 他 的 东西 都 一 样 ， 但 是 禁止 数组 类 型 的 未 受 检 转 换 比 禁 止 标量 类 型 (scalar type) 的 更 加 危 
险 ， 所 以 建议 采用 第 二 种 方案 。 但 是 在 比 Stack 更 实际 的 泛 型 类 中 ， 或 许 代码 中 会 有 多 个 地 方 
需要 从 数组 中 读 取 元 素 ， 因 此 选择 第 二 种 方案 需要 多 次 转换 成 E， 而 不 是 只 转换 成 E[]， 这 也 
是 第 一 种 方案 之 所 以 更 常用 的 原因 [Naftalin07，6.7]。 


下 面 的 程序 示范 了 泛 型 Stack 类 的 使 用 。 程 序 以 相反 的 顺序 打印 出 它 的 命令 行 参数 ， 并 转 
换 成 大 写字 母 。 如 果 要 在 从 堆栈 中 弹出 的 元 素 上 调用 String 的 toUpperCase 方 法 ， 并 不 需要 显 
式 的 转换 ， 并 且 会 确保 自动 生成 的 转换 会 成 功 : 

// Little program to exercise our generic Stack 

public static void main(String[] args) { 


Stack<String> stack = new Stack<String>(); 
for (String arg : args) . 
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stack.push(arg); 
while (!stack.isEmpty()) 
System.out.printIn(stack.popQ .toUpperCase()) ; 


看 来 上 述 的 示例 与 第 25 条 相 了 矛盾 了 ， 第 25 条 鼓励 优先 使 用 列表 而 非 数组 。 实 际 上 并 不 可 
能 总 是 或 者 总 想 在 泛 型 中 使 用 列表 。Java 并 不 是 生来 就 支持 列表 ， 因 此 有 些 泛 型 如 ArrayList， 
则 必须 在 数组 上 实现 。 为 了 提升 性 能 ， 其 他 泛 型 如 HashMap 也 在 数组 上 实现 。 


绝 大 多 数 泛 型 就 像 我 们 的 Stack 示 例 一 样 ， 因 为 它们 的 类 型 参数 没有 限制 你 可 以 创建 
Stack<Object>、Stack<int[]>、Stack<List<String>>， 或 者 任何 其 他 对 象 引 用 类 型 的 Stack 。 
注意 不 能 创建 基本 类 型 的 Stack: 企图 创建 Stack<int> 或 者 Stack<double> 会 产生 一 个 编译 时 错 
误 。 这 是 Java 泛 型 系统 根本 的 局 限 性 。 你 可 以 通过 使 用 基本 包装 类 型 (boxed primitive type) 
来 避 开 这 条 限制 〈 见 第 49 条 ) 。 l 


有 一 些 泛 型 限制 了 可 允许 的 类 型 参数 值 。 例 如 ， 考 虑 java.util.concurrent.DelayQueue, H 
声明 如 下 : 


class DelayQueue<E extends Delayed> implements BlockingQueue<E>; 


类 型 参数 列表 (<E extends Delayed>) 要 求实 际 的 类 型 参数 E 必 须 是 java.util.concurrent. 
Delayed 的 一 个 子 类 型 。 它 允许 DelayQueue 实 现 及 其 客户 端 在 DelayQueue 的 元 素 上 利用 
Delayed HH, 无需 显 式 的 转换 ， 也 没有 出 现 ClassCastException 的 风险 。 类 型 参数 E 被 称 作 有 
限制 的 类 型 参数 (bounded type parameter)。 注 意 ， 子 类 型 关系 确定 了 ， 每 个 类 型 都 是 它 自 身 
的 子 类 型 [JLS，4.10]， 因 此 创建 DelayQueue<Delayed> 是 合法 的 。 


总 而 言 之 ， 使 用 泛 型 比 使 用 需要 在 客户 端 代 码 中 进行 转换 的 类 型 来 得 更 加 安全 ， 也 更 加 容 
易 。 在 设计 新 类 型 的 时 候 ， 要 确保 它们 不 需要 这 种 转换 就 可 以 使 用 。 这 通常 意味 着 要 把 类 做 
成 是 泛 型 的 。 只 要 时 间 人 允许， 就 把 现 有 的 类 型 都 泛 型 化 。 这 对 于 这 些 类 型 的 新 用 户 来 说 会 变 
得 更 加 轻松 ， 又 不 会 破坏 现 有 的 客户 端 ( 见 第 23 条 )。 


2 型 > 113 





就 如 类 可 以 从 泛 型 中 受益 一 般 ， 方 法 也 一 样 。 静 态 工具 方法 尤其 适合 于 泛 型 化 。Collections 
中 的 所 有 “算法 ”方法 (例如 binarySearch 和 sort) 都 泛 型 化 了 。 - 


编写 泛 型 方法 与 编写 泛 型 类 型 相 类 似 。 例 如 下 面 这 个 方法 ， 它 返回 两 个 集合 的 联合 : 


// Uses raw types - unacceptable! (Item 23) 
public static Set union(Set sl, Set s2) { 
Set result = new HashSet(s1); 
result.addAl1(s2); 
return result; 


这 个 方法 可 以 编译 ,但 是 有 两 条 警告 : 


Union.java:5: warning: [unchecked] unchecked call to 
HashSet(Collection<? extends E>) as a member of raw type HashSet 
Set result = new HashSet(s1); 
A 


Union. java:6: warning: [unchecked] unchecked call to 
addAl1(Collection<? extends E>) as a member of raw type Set 
result.addAl1(s2); 
A 


为 了 修正 这 些 警 告 ， 使 方法 变 成 是 类 型 安全 的 ， 要 将 方法 声明 修改 为 声明 一 个 类 型 参数 ， 
表示 这 三 个 集合 的 元 素 类 型 (两 个 参数 和 一 个 返回 值 )， 并 在 方法 中 使 用 类 型 参数 。 声 明 类 型 参 
数 的 类 型 参数 列表 , 处 在 方法 的 修饰 符 及 其 返回 类 型 之 间 。 在 这 个 示例 中 ， 类 型 参数 列表 为 <E>， 
返回 类 型 为 Set<E>。 类 型 参数 的 命名 惯例 与 泛 型 方法 以 及 泛 型 的 相同 ( 见 第 26 条 和 第 4 条): 


// Generic method 

public static <E> Set<E> union(Set<E> sl, Set<E> s2) { 
Set<E> result = new HashSet<E>(s1); 
result.addAl1(s2); 
return result; 


} 


至 少 对 于 简单 的 泛 型 方法 而 言 ， 就 是 这 么 回 事 了 。 现 在 该 方法 编译 时 不 会 产生 任何 警告 ， 
并 提供 了 类 型 安全 性 ， 也 更 容易 使 用 。 以 下 是 一 个 执行 该 方法 的 简单 程序 。 程 序 中 不 包含 转 
换 ， 编 译 时 不 会 有 错误 或 者 警告 : 


// Simple program to exercise generic method 
public static void main(String[] args) { 
Set<String> guys = new HashSet<String>( 
Arrays.asList("Tom", "Dick", "Harry")); 
Set<String> stooges = new HashSet<String>( 
, Arrays.asList("Larry", "Moe", "Curly")); 
Set<String> aflCio = union(guys, stooges); 
System.out.printIn(aflCio); 
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运行 这 段 程序 时 ， 会 打印 出 [Moe, Harry, Tom, Curly, Larry, Dick]。 元 素 的 顺序 是 依赖 于 
实现 的 。 


union 方 法 的 局 限 性 在 于 ， 三 个 集合 的 类 型 (两 个 输入 参数 和 一 个 返回 值 ) 必须 全 部 相同 。 
利用 有 限制 的 通配符 类 型 (bounded wildcard type) ， 可 以 使 这 个 方法 变 得 更 加 灵活 ( 见 第 28 条 )。 


泛 型 方法 的 一 个 显著 特性 是 ， 无 需 明 确 指定 类 型 参数 的 值 ， 不 像 调用 泛 型 构造 器 的 时 候 是 
必须 指定 的 。 编 译 器 通过 检查 方法 参数 的 类 型 来 计算 类 型 参数 的 值 。 对 于 上 述 的 程序 而 言 ， 
编译 器 发 现 union 的 两 个 参数 都 是 Set<String> 类 型 ， 因 此 知道 类 型 参数 E 必 须 为 String。 这 个 过 
程 称 作 类 型 推导 (type inference), 


如 第 1 条 所 述 ， 可 以 利用 泛 型 方法 调用 所 提供 的 类 型 推导 ， 使 创建 参数 化 类 型 实例 的 过 程 
恋 得 更 加 轻松 。 提 醒 一 下 : 在 调用 泛 型 构造 器 的 时 候 ， 要 明确 传递 类 型 参数 的 值 可 能 有 点 麻 
烦 。 类 型 参数 出 现在 了 变量 声明 的 左右 两 边 ， 显 得 有 些 元 余 : 

// Parameterized type instance creation with constructor 


Map<String, List<String>> anagrams = 
new HashMap<String, List<String>>(); 


为 了 消除 这 种 宛 余 ， 可 以 编写 一 个 泛 型 静态 工厂 方法 (generic static factory method), 与 
想 要 使 用 的 每 个 构造 器 相对 应 。 例 如 ， 下 面 是 一 个 与 无 参 的 HashMap 构 造 器 相对 应 的 泛 型 静 
BLT HE: 

// Generic static factory method 

public static <K,V> HashMap<K,V> newHashMap() { 


return new HashMap<K,V>(); 
} 


通过 这 个 泛 型 静态 工厂 方法 ， 可 以 用 下 面 这 段 简洁 的 代码 来 取代 上 面 那个 重复 的 声明 : 


// Parameterized type instance creation with static factory 

Map<String, List<String>> anagrams = newHashMap() ; 

在 泛 型 上 调用 构造 器 时 ， 如 果 语 言 所 做 的 类 型 推导 与 调用 泛 型 方法 时 所 做 的 相同 ， 那 就 好 
了 。 将 来 的 某 一 天 也 许可 以 实现 这 一 点 ， 但 截至 Java 1.6 发 行 版 本 还 不 行 。 


相关 的 模式 是 泛 型 单 例 工厂 (generic singleton factory) 。 有 了 时， 会 需要 创建 不 可 变 但 又 
适合 于 许多 不 同类 型 的 对 象 。 由 于 泛 型 是 通过 擦 除 ( 见 第 25 条 ) 实现 的 ， 可 以 给 所 有 必要 的 
类 型 参数 使 用 单个 对 象 ， 但 是 需要 编写 一 个 静态 工厂 方法 ， 重 复 地 给 每 个 必要 的 类 型 参数 分 
发 对 象 。 这 种 模式 最 常用 于 函数 对 象 ( 见 第 21 条 )， 如 Collections.reverseOrder， 但 也 适用 于 
像 Collections.emptySet 这 样 的 集合 。 


假设 有 一 个 接口 ， 描 述 了 一 个 方法 ， 该 方法 接受 和 返回 某 个 类 型 T 的 值 : 
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public interface UnaryFunction<T> { 
T apply(T arg); 


现在 假设 要 提供 一 个 恒 等 函 数 (identity function)。 如 果 在 每 次 需要 的 时 候 都 重新 创建 一 
个 ， 这 样 会 很 浪费 ， 因 为 它 是 无 状态 的 (stateless) 。 如 果 泛 型 被 具体 化 了 ， 每 个 类 型 都 需要 
一 个 恒 等 函 数 ， 但 是 它们 被 擦 除 以 后 ， 就 只 需要 一 个 泛 型 单 例 。 请 看 以 下 示例 : 

// Ceneric singleton factory pattern 

private static UnaryFunction<Object> IDENTITY_FUNCTION = 


new UnaryFunction<Object>() { 
public Object apply(Object arg) { return arg; } 


// IDENTITY_FUNCTION is stateless and its type parameter is 
// unbounded so it's safe to share one instance across all types. 
@SuppressWarnings ("unchecked") 
public static <T> UnaryFunction<T> identityFunction() { 
return (UnaryFunction<T>) IDENTITY_FUNCTION; 


IDENTITY_FUNCTION 转 换 成 (UnaryFunction<T>)， 产 生 了 一 条 未 受 检 的 转换 警告 ， 因 
为 UnaryFunction<Object> 对 于 每 个 T 来 说 并 非 都 是 个 UnaryFunction<T>。 但 是 恒 等 函 数 很 特 
殊 : 它 返回 未 被 修改 的 参数 ， 因 此 我 们 知道 无 论 T 的 值 是 什么 ， 用 它 作为 UnaryFunction<T> 都 
是 类 型 安全 的 。 因 此 ， 我 们 可 以 放心 地 禁止 由 这 个 转换 所 产生 的 未 受 检 转 换 警 告 。 一 旦 禁止 ， 
代码 在 编译 时 就 不 会 出 现任 何 错误 或 者 警告 。 


以 下 是 一 个 范例 程序 ， 利 用 泛 型 单 例 作 为 UnaryFunction<String> 和 UnaryFunction 
<Number>。 像 往常 一 样 ， 它 不 包含 转换 ， 编 译 时 没有 出 现 错误 或 者 警告 : 


// Sample program to exercise generic singleton 

public static void main(String[] args) { 
String[] strings = { "jute", "hemp", "nylon" }; 
UnaryFunction<String> sameString = identityFunction(); 
for (String s : strings) 

System.out.printIn(sameString.apply(s)); 

Number[{] numbers = { 1, 2.0, 3L }; 
UnaryFunction<Number> sameNumber = identityFunctionQ; 
for (Number n : numbers) 


System.out.printIn(sameNumber.apply(n)); 
} 


虽然 相对 少见 ， 但 是 通过 某 个 包含 该 类 型 参数 本 身 的 表达 式 来 限制 类 型 参数 是 允许 的 。 这 
就 是 递归 类 型 限制 (recursive type bound) 。 递 归 类 型 限制 最 普遍 的 用 途 与 Comparable 接 口 
有 关 ， 它 定义 类 型 的 自然 顺序 : 


public interface Comparable<T> { 
int compareTo(T o); 
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类 型 参数 T 定 义 的 类 型 ， 可 以 与 实现 Comparable<T> 的 类 型 的 元 素 进行 比较 。 实 际 上 ， 几 
乎 所 有 的 类 型 都 只 能 与 它们 自身 的 类 型 的 元 素 相 比较 。 因 此 ， 例 如 String 实 现 Comparable 
<String>，Integer 实 现 Comparable<Integer>， 等 等 。 


有 许多 方法 都 带 有 一 个 实现 Comparable 接 口 的 元 素 列 表 ， 为 了 对 列表 进行 排序 ， 并 在 其 
中 进行 搜索 ， 计 算出 它 的 最 小 值 或 者 最 大 值 ， 等 等 。 要 完成 这 其 中 的 任何 一 项 工作 ， 要 求 列 
表 中 的 每 个 元 素 要 都 能 够 与 列表 中 的 每 个 其 他 元 素 相 比较 ， 换 句 话 说， 列表 的 元 素 可 以 互相 
比较 (mutually comparable) 。 下 面 是 如 何 表达 这 种 约束 条 件 的 一 个 示例 : 


// Using a recursive type bound to express mutual comparability 
public static <T extends Comparable<T>> T max(List<T> list) {...} 


类 型 限制 <T extends Comparable<T>>， 可 以 读 作 “针对 可 以 与 自身 进行 比较 的 每 个 类 型 
T”， 这 与 互 比 性 的 概念 或 多 或 少 有 些 一 致 。 


下 面 的 方法 就 带 有 上 述 声明 。 它 根据 元 素 的 自然 顺序 计算 列表 的 最 大 值 ， 编 译 时 没有 出 现 
错误 或 者 警告 : 
// Returns the maximum value in a list - uses recursive type bound 
public static <T extends Comparable<T>> T max(List<T> list) { 
Iterator<T> i = list.iterator(); 
T result = i.nextQ; 
while (i.hasNext()) { 
Tt = i.next(); 
if (t.compareTo(result) > 0) 
result = t; 
} 


return result; 
} 
递归 类 型 限制 可 能 比 这 个 要 复杂 得 多 ， 但 幸运 的 是 ， 这 种 情况 并 不 经 常 发 生 。 如 果 你 理 
解 了 这 种 习惯 用 法 及 其 通配符 变量 ( 见 第 28 条 )， 就 能 够 处 理 在 实践 中 遇 到 的 许多 递归 类 型 限 
制 了 。 


总 而 言 之 ,， 泛 型 方法 就 像 泛 型 一 样 ， 使 用 起 来 比 要 求 客户 端 转换 输入 参数 并 返回 值 的 方法 
来 得 更 加 安全 ， 也 更 加 容易 。 就 像 类 型 一 样 ， 你 应 该 确保 新 方法 可 以 不 用 转换 就 能 使 用 ， 这 
通常 意味 着 要 将 它们 泛 型 化 。 并 且 就 像 类 型 一 样 ， 还 应 该 将 现 有 的 方法 泛 型 化 ， 使 新 用 户 使 
用 起 来 更 加 轻松 ， 且 不 会 破坏 现 有 的 客户 端 ( 见 第 23 条 )。 
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如 第 25 条 所 述 ， 参 数 化 类 型 是 不 可 变 的 (invariant)。 换 名 话说， 对 于 任何 两 个 截然 不 同 
的 类 型 Type1 和 Type2 而 言 ，List<Typel> 既 不 是 List<Type2> 的 子 类 型 ， 也 不 是 它 的 超 类 型 。 
虽然 List<String> 不 是 List<Object> 的 子 类 型 ， 这 与 直觉 相悖 ， 但 是 实际 上 很 有 意义 。 你 可 以 
将 任何 对 象 放 进 一 个 List<Object> 中 ， 却 只 能 将 字符 串 放 进 List<String> 中 。 


有 时 候 ， 我 们 需要 的 灵活 性 要 比 不 可 变 类 型 所 能 提供 的 更 多 。 考 虑 第 26 条 中 的 堆栈 下 面 
就 是 它 的 公共 API: 
public class Stack<E> { 
public StackQ); 
public void push(E e); 


public E pop(); 
public boolean isEmpty(); 


假设 我 们 想 要 增加 一 个 方法 ， 让 它 按 顺序 将 一 系列 的 元 素 全 部 放 到 堆栈 中 。 这 是 第 一 次 党 
试 ， 如 下 : 

// pushA11 method without wildcard type - deficient! 

public void pushAll(Iterable<E> src) { 


for (E e : src) 
push(e); 


这 个 方法 编译 时 正确 无 误 ， 但 是 并 非 尽 如 人 意 。 如 果 Iterable src 的 元 素 类 型 与 堆栈 的 完全 
匹配 ， 就 没有 问题 。 但 是 假如 有 一 个 Stack<Number>， 并 且 调 用 了 push(intVal)， 这 里 的 intVal 
就 是 Integer 类 型 。 这 是 可 以 的 ， 因 为 Integer 是 Number 的 一 个 子 类 型 。 因 此 从 逻辑 上 来 说 ， 下 
面 这 个 方法 应 该 也 可 以 : 

Stack<Number> numberStack = new Stack<Number>(); 


Iterable<Integer> integers = ... ; 
numberStack.pushAl11(integers) ; 


但 是 ， 如 果 尝 试 这 么 做 ， 就 会 得 到 下 面 的 错误 消息 ， 因 为 如 前 所 述 ， 参 数 化 类 型 是 不 
可 变 的 : 
StackTest.java:7: pushAll(Iterable<Number>) in Stack<Number> 


Cannot be applied to (Iterable<Integer>) 
numberStack.pushA11 (integers); 
A 


幸运 的 是 ， 有 一 种 解决 办 法 。Java 提 供 了 一 种 特殊 的 参数 化 类 型 ， 称 作 有 限制 的 通配符 类 
型 (bounded wildcard type)， 来 处 理 类 似 的 情况 。pushAll 的 输入 参数 类 型 不 应 该 为 “E 的 
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Iterable 接 口 "， 而 应 该 为 “E 的 某 个 子 类 型 的 Iterable 接 口 "， 有 一 个 通配符 类 型 正 符合 此 意 : 
Iterable<? Extends E>。( 使 用 关键 字 extends 有 些 误导 : 回忆 一 下 第 26 条 中 的 说 法 ， 确 定 了 子 
类 型 (subtype) 后 ， 每 个 类 型 便 都 是 自身 的 子 类 型 ， 即 便 它 没有 将 自身 扩展 。) 我 们 修改 一 下 
pushAll 来 使 用 这 个 类 型 , 


// Wildcard type for parameter that serves as an E producer 
public void pushAll(Iterable<? extends E> src) { 
for (E e : src) 
push(e); 
} 


这 么 修改 了 之 后 ， 不 仅 Stack 可 以 正确 无 误 地 编译 ， 没 有 通过 初始 的 pushAll 声 明 进 行 编译 
的 客户 端 代码 也 一 样 可 以 。 因 为 Stack 及 其 客户 端正 确 无 误 地 进行 了 编译 ， 你 就 知道 一 切 都 是 
类 型 安全 的 了 。 l i 


现在 假设 想 要 编写 一 个 pushAll 方 法 ， 使 之 与 popAll 方 法 相 呼 应 。popAll 方 法 从 堆栈 中 
弹出 每 个 元 素 ， 并 将 这 些 元 素 添加 到 指定 的 集合 中 。 初 次 尝试 编写 的 popAll 方 法 可 能 像 下 面 
这 样 : 

// popA11 method without wildcard type - deficient! 

public void popA11(Co11ection<E> dst) { 

while (!isEmpty()) 


dst.add(pop()); 
} 


如 果 目 标 集 合 的 元 素 类 型 与 堆栈 的 完全 匹配 ， 这 段 代码 编译 时 还 是 会 正确 无 误 ， 运 行 得 很 
好 。 但 是 ， 也 并 不 意味 着 尽 如 人 意 。 假 设 你 有 一 个 Stack<Number> 和 类 型 Object 的 变量 。 如 果 
从 堆栈 中 弹出 一 个 元 素 ， 并 将 它 保存 在 该 变量 中 ， 它 的 编译 和 运行 都 不 会 出 错 ， 那 你 为 何不 
能 也 这 么 做 呢 ? 

Stack<Number> numberStack = new Stack<Number>(); 


Collection<Object> objects = .. 
numberStack.popAl1 (objects); 


如 果 试 着 用 上 述 的 popAll 版 本 编译 这 段 客户 端 代 码 ， 就 会 得 到 一 个 非常 类 似 于 第 一 次 用 
pushAll 时 所 得 到 的 错误 ; Collection<Object> 不 是 Collection<Number> 的 子 类 型 。 这 一 次 , 通 
配 符 类 型 同样 提供 了 一 种 解决 办 法 。popAll 的 输入 参数 类 型 不 应 该 为 “E 的 集合 ”"， 而 应 该 为 
“E 的 某 种 超 类 的 集合 ”( 这 里 的 超 类 是 确定 的 ， 因 此 E 是 它 自身 的 一 个 超 类 型 [JLS，4.10])。 
仍然 有 一 个 通配符 类 型 正 是 符合 此 意 : Collection<? super E>。 让 我 们 修改 popAll 来 使 用 它 : 

// Wildcard type for parameter that serves as an E consumer 

public void popAll(Collection<? super E> dst) { 

while (!isEmpty()) 


dst.add(pop()); 
} 
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做 了 这 个 变动 之 后 ，Stack 和 客户 端 代码 就 都 可 以 正确 无 误 地 编译 了 。 


结论 很 明显 。 为 了 获得 最 大 限度 的 灵活 性 ， 要 在 表示 生产 者 或 者 消费 者 的 输入 参数 上 使 用 
通配符 类 型 。 如 果 某 个 输入 参数 既是 生产 者 ， 又 是 消费 者 ， 那 么 通配符 类 型 对 你 就 没有 什么 
好 处 了 : 因为 你 需要 的 是 严格 的 类 型 匹配 ， 这 是 不 用 任何 通配符 而 得 到 的 。 


下 面 的 助 记 符 便于 让 你 记 住 要 使 用 哪 种 通配符 类 型 : 
PECS 表 示 producer-extends，consumer-super 。 


换 句 话说 ， 如 果 参 数 化 类 型 表示 一 个 T 生 产 者 ， 就 使 用 <? extends T>， 如 果 它 表示 一 个 T 
消费 者 ， 就 使 用 <? super T>。 在 我 们 的 Stack 示 例 中 ，pushAll 的 src 参 数 产生 E 实 例 供 Stack 使 
用 ， 因 此 src 相 应 的 类 型 为 Iterable<? extends E>; popAll 的 dst 参 数 通过 Stack 消 费 E 实 例 ， 因 此 
dst 相 应 的 类 型 为 Collection<? super E>。PECS 这 个 助 记 符 突出 了 使 用 通配符 类 型 的 基本 原则 。 
Naftalin 和 Wadler 称 之 为 Get and Put Principle [Naftalin07，2.4]。 


记 住 这 个 助 记 符 ,我 们 下 面 来 看 一 些 之 前 的 条 目 中 提 到 过 的 方法 声明 。 第 25 条 中 的 reduce 
方法 就 有 这 条 声明 : 


static <E> E reduce(List<E> list, Function<E> f, E initVal) 


RJK BE AY DAA Se AT PAE A, ，reduce 方 法 还 是 只 用 它 的 list 参 数 作为 也 生产 者 
(producer) ， 因 此 它 的 声明 就 应 该 使 用 一 个 extends E 的 通配符 类 型 。 参 数 f 表 示 既 可 以 消费 又 
可 以 产生 E 实 例 的 函数 ， 因 此 通配符 类 型 不 适合 它 。 得 到 的 方法 声明 如 下 : 


// Wildcard type for parameter that serves as an E producer 
static <E> E reduce(List<? extends E> list, Function<E> f, 
E initVal) 


这 一 变化 实际 上 有 什么 区 别 吗 ? 事实 上 ， 的 确 有 区 别 。 假 设 你 有 一 个 List<Integer>， 想 通 
过 Function<Number> 把 它 简 化 。 它 不 能 通过 初始 声明 进行 编译 ， 但 是 一 旦 添加 了 有 限制 的 通 
配 符 类 型 ， 就 可 以 了 。 


现在 让 我 们 看 看 第 27 条 中 的 union 方 法 。 下 面 是 声明 : 
public static <E> Set<E> union(Set<E> sl, Set<E> s2) 
sl1 和 s2 这 两 个 参数 都 是 E 消 费 者 ， 因 此 根据 PECS， 这 个 声明 应 该 是 : 


public static <E> Set<E> union(Set<? extends E> sl, 
Set<? extends E> s2) 


注意 返回 类 型 仍然 是 Set<E>。 不 要 用 通配符 类 型 作为 返回 类 型 。 除 了 为 用 户 提供 额外 的 
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灵活 性 之 外 ， 它 还 会 强制 用 户 在 客户 端 代 码 中 使 用 通配符 类 型 。 


如 果 使 用 得 当 ， 通 配 符 类 型 对 于 类 的 用 户 来 说 几乎 是 无 形 的 。 它 们 使 方法 能 够 接受 它们 应 
该 接受 的 参数 ， 并 拒绝 那些 应 该 拒绝 的 参数 。 如 果 类 的 用 户 必 须 考虑 通配符 类 型 ， 类 的 API 或 
许 就 会 出 错 。 


遗憾 的 是 ， 类 型 推导 (type inference) 规则 相当 复杂 ， 在 语言 规范 中 占 了 整整 16 页 UJLS， 
15.12.2.7-8]， 而 且 它 们 并 非 总 能 完成 需要 它们 完成 的 工作 。 看 看 修改 过 的 union 声 明 ， 你 可 能 
会 以 为 可 以 像 这 样 编写 : | 

Set<Integer> integers = ... ; 


Set<Double> doubles = ... ; 
Set<Number> numbers = union(integers, doubles); 


但 这 么 做 会 得 到 下 面 的 错误 消息 : 


Union.java:14: incompatible types 
found : Set<Number & Comparable<? extends Number & 
Comparable<?>>> 
required: Set<Number> 
Set<Number> numbers = union(integers, doubles); 
人 


幸运 的 是 ， 有 一 种 办 法 可 以 处 理 这 种 错误 。 如 果 编 译 器 不 能 推断 你 希望 它 拥 有 的 类 型 ， 可 
以 通过 一 个 显 式 的 类 型 参数 (explicit type parameter) 来 告诉 它 要 使 用 哪 种 类 型 。 这 种 情况 不 
太 经 常 发 生 ， 这 是 好 事 ， 因 为 显 式 的 类 型 参数 不 太 优 雅 。 增 加 了 这 个 显 式 的 类 型 参数 之 后 ， 
程序 可 以 正确 无 误 地 进行 编译 : 


Set<Number> numbers = Union.<Number>union(integers, doubles); 


接 下 来 ， 我 们 把 注意 力 转向 第 27 条 中 的 max 方 法 。 以 下 是 初始 的 声明 : 


public static <T extends Comparable<T>> T max(List<T> list) 
下 面 是 修改 过 的 使 用 通配符 类 型 的 声明 : 


public static <T extends Comparable<? super T>> T max( 
List<? extends T> list) 


为 了 从 初始 声明 中 得 到 修改 后 的 版 本 ,要 应 用 PECS 转 换 两 次 。 最 直接 的 是 运用 到 参数 list。 
它 产 生 T 实 例 ， 因 此 将 类 型 从 List<T> 改 成 List<? extends T>。 更 灵活 的 是 运用 到 类 型 参数 T。 
这 是 我 们 第 一 次 见 到 将 通配符 运用 到 类 型 参数 。 最 初 T 被 指定 用 来 扩展 Comparable<T>， 但 是 
T 的 comparable 消 费 T 实 例 (并 产生 表示 顺序 关系 的 整 值 ) 。 因 此 ， 参 数 化 类 型 Comparable<T> 
被 有 限制 通配符 类 型 Comparable<? super T> 取 代 。comparable 始 终 是 消费 者 ， 因 此 使 用 时 始 
终 应 该 是 Comparable<? super T> 优 先 于 Comparable<T>。 对 于 comparator 也 一 样 ， 因 此 使 
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用 时 始终 应 该 是 Comparator<? super T> 优 先 于 Comparator<T>。 


修改 过 的 max 声 明 可 能 是 整 本 书 中 最 复杂 的 方法 声明 了 。 所 增加 的 复杂 代码 真 的 起 作用 了 
A? 是 的 ， 起 作用 了 。 下 面 是 一 个 简单 的 列表 示例 ， 在 初始 的 声明 中 不 允许 这 样 ， 修 改过 的 
版 本 则 可 以 : 


List<ScheduledFuture<?>> scheduledFutures = ... ; 


不 能 将 初始 方法 声明 运用 给 这 个 列表 的 原因 在 于 ，java.util.concurrent.ScheduledFuture 没 
有 实现 Comparable<ScheduledFuture> 接 口 。 相 反 ， 它 是 扩展 Comparable<Delayed> 接 口 的 
Delayed 接 口 的 子 接口 。 换 句 话 说 ，ScheduleFuture 实 例 并 非 只 能 与 其 他 ScheduledFuture 实 例 
相 比 较 ， 它 可 以 与 任何 Delayed 实 例 相 比较 ， 这 就 是 以 导致 初始 声明 时 就 会 被 拒绝 。 


修改 过 的 max 声 明 有 一 个 小 小 的 问题 ， 它 阻止 方法 进行 编译 。 下 面 的 方法 包含 了 修改 过 的 
声明 ; 
// Won't compile - wildcards can require change in method body! 
public static <T extends Comparable<? super T>> T max( 
List<? extends T> list) { 
Iterator<T> i = list.iterator(; 
T result = i.nextQ; 
while (i.hasNextQ)) { 
T t = i.nextQ); 
if (t.compareTo(result) > 0) 
result = t; 


return result; 


} 
以 下 是 它 编译 时 会 产生 的 错误 消息 : 


Max.java:7: incompatible types 
found : Iterator<capture#591 of ? extends T> 
required: Iterator<T> 
Iterator<T> i = list.iterator(); 
A 


这 条 错误 消息 意味 着 什么 , 我 们 又 该 如 何 修正 这 个 问题 呢 ? 它 意 味 着 list 不 是 一 个 List<T>， 
因此 它 的 iterator 方 法 没有 返回 Iterator<T>。 它 返回 T 的 某 个 子 类 型 的 一 个 iterator， 因 此 我 们 用 
它 代替 iterator 声 明 ， 它 使 用 了 一 个 有 限制 的 通配符 类 型 : 


Iterator<? extends T> i = list.iterator(); 


这 是 必须 对 方法 体 所 做 的 唯一 修改 。 迭 代 器 的 next 方 法 返回 的 元 素 属于 T 的 某 个 子 类 型 ， 
因此 它们 可 以 被 安全 地 保存 在 类 型 T 的 一 个 变量 中 。 


还 有 一 个 与 通配符 有 关 的 话题 值得 探讨 。 类 型 参数 和 通配符 之 间 具 有 双重 性 ， 许 多 方法 都 可 
以 利用 其 中 一 个 或 者 另 一 个 进行 声明 。 例 如 ,下面 是 可 能 的 两 种 静态 方法 声明 ， 来 交换 列表 中 的 
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两 个 被 索引 的 项 目 。 第 一 个 使 用 无 限制 的 类 型 参数 ( 见 第 27 条 )， 第 二 个 使 用 无 限制 的 通配符 : 


// Two possible declarations for the swap method 

public static <E> void swap(List<E> list, int i, int j); 

public static void swap(List<?> list, int i, int j); 

你 更 喜欢 这 两 种 方法 中 的 哪 一 种 呢 ? 为 什么 ? 在 公共 API 中 ， 第 二 种 更 好 一 些 ， 因 为 它 更 简 
单 。 将 它 传 到 一 个 列表 中 一 一 任何 列表 一 一 方法 就 会 交换 被 索引 的 元 素 。 不 用 担心 类 型 参数 。 一 
般 来 说 ， 如 果 类 型 参数 只 在 方法 声明 中 出 现 一 次 ， 就 可 以 用 通配符 取代 它 。 如 果 是 无 限制 的 类 
型 参数 ， 就 用 无 限制 的 通配符 取代 它 ， 如 果 是 有 限制 的 类 型 参数 ， 就 用 有 限制 的 通配符 取代 它 。 


将 第 二 种 声明 用 于 swap 方 法 会 有 一 个 问题 ， 它 优先 使 用 通配符 而 非 类 型 参数 : 下 面 这 个 
简单 的 实现 都 不 能 编译 : 


public static void swap(List<?> list, int i, int j) { 
list.set(i, list.set(j, list.get(i))); 
} 


试 着 编译 时 会 产生 这 条 没有 什么 用 处 的 错误 消息 : 


Swap.java:5: set(int,capture#282 of ?) in List<capture#282 of ?> 
cannot be applied to (int,Object) 
list.set(i, list.set(j, list.get(i))); 
A 


不 能 将 元 素 放 回 到 刚刚 从 中 取出 的 列表 中 ， 这 似乎 不 太 对 劲 。 问 题 在 于 list 的 类 型 为 
List<?>， 你 不 能 把 null 之 外 的 任何 值 放 到 List<?> 中 。 幸 运 的 是 ， 有 一 种 方式 可 以 实现 这 个 方 
法 ， 无 需求 助 于 不 安全 的 转换 或 者 原生 态 类 型 (raw type)。 这 种 想法 就 是 编写 一 个 私有 的 辅 
助 方法 来 捕捉 通配符 类 型 。 为 了 捕捉 类 型 ， 辅 助 方法 必须 是 证 型 方法 ， 像 下 面 这样 ; 


public static void swap(List<?> list, int i, int j) { 
swapHelper(list, i, j); 


// Private helper method for wildcard capture 
private static <E> void swapHelper(List<E> list, int i, int j) { 
list.set(i, list.set(j, list.get(i))); 


swapHelper 方 法 知道 list 是 一 个 List<E>。 因 此 ， 它 知道 从 这 个 列表 中 取出 的 任何 值 均 为 E 类 型 ， 
并 且 知 道 将 E 类 型 的 任何 值 放 进 列表 都 是 安全 的 。swap 这 个 有 些 费 解 的 实现 编译 起 来 却 是 正确 无 
误 的 。 它 允许 我 们 导出 swap 这 个 比较 好 的 基于 通配符 的 声明 ， 同 时 在 内 部 利用 更 加 复杂 的 泛 型 方 
法 。swap 方 法 的 客户 端 不 一 定 要 面 对 更 加 复杂 的 swapHelper 声 明 ， 但 是 它们 的 确 从 中 受益 。， 


总 而 言 之 ， 在 API 中 使 用 通配符 类 型 虽然 比较 需要 技巧 ， 但 是 使 API 变 得 灵活 得 多 。 如 果 编 
写 的 是 将 被 广泛 使 用 的 类 库 ， 则 一 定 要 适当 地 利用 通配符 类 型 。 记 住 基本 的 原则 : producer- 
extends, consumer-super (PECS)。 还 要 记 住 所 有 的 comparable 和 comparator 都 是 消费 者 。 
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泛 型 最 常用 于 集合 ， 如 Set 和 Map ， 以 及 单元 素 的 容器 ， 如 FThreadLocal 和 Atomic 
Reference。 在 这 些 用 法 中 ， 它 都 充当 被 参数 化 了 的 容器 。 这 样 就 限制 你 每 个 容器 只 能 有 固定 
数目 的 类 型 参数 。 一 般 来 说 ， 这 种 情况 正 是 你 想 要 的 。 一 个 Set 只 有 一 个 类 型 参数 ， 表 示 它 的 
元 素 类 型 ， 一 个 Map 有 两 个 类 型 参数 ， 表 示 它 的 键 和 值 类 型 ， 诸 如 此 类 。 


但 是 ， 有 时 候 你 会 需要 更 多 的 灵活 性 。 例如 ,数据 库 行 可 以 有 任意 多 的 列 ， 如 果 能 以 类 型 
安全 的 方式 访问 所 有 列 就 好 了 。 幸 运 的 是 ， 有 一 种 方法 可 以 很 容易 地 做 到 这 一 点 。 这 种 想法 
就 是 将 键 (key) 进行 参数 化 而 不 是 将 容器 (container) 参数 化 。 然 后 将 参数 化 的 键 提交 给 容 
器 ， 来 插入 或 者 获取 值 。 用 泛 型 系统 来 确保 值 的 类 型 与 它 的 键 相 符 。 


简单 地 示范 一 下 这 种 方法 : 考虑 Favorites 类 ， 它 允许 其 客户 端 从 任意 数量 的 其 他 类 中 ， 保 
存 并 获取 一 个 “最 喜爱 ”的 实例 。Class 对 象 充当 参数 化 键 的 部 分 。 之 所 以 可 以 这 样 ， 是 因为 
类 Class 在 Java 1.5 版 本 中 被 泛 型 化 了 。 类 的 类 型 从 字面 上 来 看 不 再 只 是 简单 的 Class， 而 是 
Class<T>。 例 如 ，String.class 属 于 Class<String> 类 型 ，Integer.class 属 于 Class<Integer> 类 


型 。 当 一 个 类 的 字面 文字 被 用 在 方法 中 ， 来 传达 编译 时 和 运行 时 的 类 型 信息 上 时， 就 被 称 作 
type token[Brancha04]。 i 


Favorites 类 的 API 很 简单 。 它 看 起 来 就 像 一 个 简单 的 map ， 除 了 键 (而 不 是 map) 被 参数 
化 之 外 。 客 户 端 在 设置 和 获取 最 喜爱 的 实例 时 提交 Class 对 象 。 下 面 就 是 这 个 API: 


// Typesafe heterogeneous container pattern - API 

public class Favorites { 
public <T> void putFavorite(Class<T> type, T instance); 
public <T> T getFavorite(Class<T> type); 

} 


下 面 是 一 个 示例 程序 ， 检 验 一 下 Favorites 类 ， 它 保存 、 获 取 并 打印 一 个 最 喜爱 的 String、 
Integer 和 Class 实 例 : 


// Typesafe heterogeneous container pattern - client 
public static void main(String[] args) { 
Favorites f = new Favorites(); 
f.putFavorite(String.class, “Java"); 
f.putFavorite(Integer.class, @xcafebabe) ; 
f.putFavorite(Class.class, Favorites.class); 
String favoriteString = f.getFavorite(String.class); 
int favoriteInteger = f.getFavorite(Integer.class); 
Class<?> favoriteClass = f.getFavorite(Class.class); 
System.out.printf("%s %x %s%n", favoriteString, 
favoriteInteger, favoriteClass.getName()); 


i 
正如 所 料 ， 这 段 程序 打印 出 的 是 Java cafebabe Favorites。 


Favorites 实 例 是 类 型 安全 (typesafe) 的 : 当 你 向 它 请 求 String 的 时 候 ， 它 从 来 不 会 返回 
一 个 Integer 给 你 。 同 时 它 也 是 异 构 的 (heterogeneous) : 不 像 普通 的 map， 它 的 所 有 键 都 是 不 
同类 型 的 。 因 此 ， 我 们 将 Favorites 称 作 类 型 安全 的 异 构 容 器 (typesafe heterogeneous 


container) 。 


Favorites 的 实现 小 得 出 奇 。 它 的 完整 实现 如 下 : 


// Typesafe heterogeneous container pattern - implementation 
public class Favorites { 
. private Map<Class<?>, Object> favorites = 
new HashMap<Class<?>, Object>(); 
public <T> void putFavorite(Class<T> type, T instance) { 
if (type == null) 
throw new NullPointerException("Type is null"); 
favorites.put(type, instance); 


public <T> T getFavorite(Class<T> type) { 
return type.cast(favorites.get(type)); 
} 


这 里 发 生 了 一 些微 妙 的 事情 。 每 个 Favorites 实 例 都 得 到 一 个 称 作 favorites 的 私有 
Map<Class<?>，Object> 的 支持 。 你 可 能 认为 由 于 无 限制 通配符 类 型 的 关系 ， 将 不 能 把 任何 东 
西 放 进 这 个 Map 中 ， 但 事实 正好 相反 。 要 注意 的 是 通配符 类 型 是 嵌 套 的 : 它 不 是 属于 通配符 类 
型 的 Map 的 类 型 ， 而 是 它 的 键 的 类 型 。 由 此 可 见 ， 每 个 键 都 可 以 有 一 个 不 同 的 参数 化 类 型 : 一 
个 可 以 是 Class<String>， 接 下 来 是 Class<Integer> 等 等 。 异 构 就 是 从 这 里 来 的 。 


第 二 件 要 注意 的 事情 是 ，favorites Map 的 值 类 型 只 是 Object。 换 句 话说 ，Map 并 不 能 保 
证 键 和 值 之 间 的 类 型 关系 ， 即 不 能 保证 每 个 值 的 类 型 都 与 键 的 类 型 相同 。 事 实 上 ，Java 的 类 
型 系统 还 没有 强大 到 足以 表达 这 一 点 。 但 我 们 知道 这 是 事实 ， 并 在 获取 favorite 的 时 候 利用 了 
ix Kh. 


putFavorite 方 法 的 实现 很 简单 : 它 只 是 把 (从 指定 的 Class 对 象 到 指定 favorite 实 例 的 ) 一 
个 映射 放 到 favorites 中 。 如 前 所 述 ， 这 是 放弃 了 键 和 值 之 间 的 “类 型 联系 "， 因 此 无 法 知道 这 
个 值 是 键 的 一 个 实例 。 但 是 没关系 ， 因 为 getFavorites 方 法 能 够 并 且 的 确 重新 建立 了 这 种 联系 。 


getFavorite 方 法 的 实现 比 putFavorite 的 更 难 一 些 。 它 先 从 favorites 映 射 中 获得 与 指定 
Class 对 象 相 对 应 的 值 。 这 正 是 要 返回 的 对 象 引 用 ， 但 它 的 编译 时 类 型 是 错误 的 。 它 的 类 
型 只 是 Object (favorites 映 射 的 值 类 型 )， 我 们 需要 返回 一 个 T。 因 此 ，getFavorite 方 法 的 
实现 利用 Class 的 cast 方 法 ， 将 对 象 引 用 动态 地 转换 (dynamically cast) 成 了 Class 对 象 所 
表示 的 类 型 。 
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cast 方 法 是 Java 的 cast 操 作 符 的 动态 模拟 。 它 只 检验 它 的 参数 是 否 为 Class 对 象 所 表示 的 类 
型 的 实例 。 如 果 是 ， 就 返回 参数 ， 否 则 就 抛 出 ClassCastException 异 常 。 我 们 知道 ， 
getFavorite 中 的 cast 调 用 永远 不 会 抛 出 ClassCastException 异 常 ， 并 假设 客户 端 代码 正确 无 误 
地 进行 了 编译 。 也 就 是 说 ， 我 们 知道 favorites 映 射 中 的 值 会 始终 与 键 的 类 型 相 匹 配 。 


假设 cast 方 法 只 返回 它 的 参数 ， 那 它 能 为 我 们 做 什么 呢 ? cast 方 法 的 签名 充分 利用 了 Class 
类 被 泛 型 化 的 这 个 事实 。 它 的 返回 类 型 是 Class 对 象 的 类 型 参数 : 


public class Class<T> { 
T cast(Object obj); 


这 正 是 getFavorite 方 法 所 需要 的 ， 也 正 是 让 我 们 不 必 借助 于 未 受 检 地 转换 成 [就 能 确保 
Favorites 类 型 安全 的 东西 。 


Favorites 类 有 两 种 局 限 性 值得 注意 。 首 先 ， 恶 意 的 客户 端 可 以 很 轻松 地 破坏 Favorites 实 例 
的 类 型 安全 ， 只 要 以 它 的 原生 态 形 式 (raw form) 使 用 Class 对 象 。 但 会 造成 客户 端 代码 在 纺 
译 时 产生 未 受 检 的 警告 。 这 与 一 般 的 集合 实现 ， 如 HashSet 和 HashMap 并 没有 什么 区 别 。 你 可 
以 很 容易 地 利用 原生 态 类 型 HashSet ( 见 第 23 条 ) 将 String 放 进 HashSet<Integer> 中 。 也 就 是 说 ， 
如 果 愿 意 付 出 一 点 点 代价 ， 就 可 以 拥有 运行 时 的 类 型 安全 。 确 保 Favorites 永 远 不 违背 它 的 类 
型 约束 条 件 的 方式 是 ， 让 putFavorite 方 法 检验 instance 是 否 真 的 是 type 所 表示 的 类 型 的 实例 。 
我 们 已 经 知道 这 要 如 何 进行 了 ， 只 要 使 用 一 个 动态 的 转换 : 

// Achieving runtime type safety with a dynamic cast 

public <T> void putFavorite(Class<T> type, T instance) { 


favorites.put(type, type.cast(instance)); 


} 


java.util.Collections 中 有 一 些 集 合 包 装 类 采用 了 同样 的 技巧 。 它们 称 作 checkedSet、 
checkedList、checkedMap ， 诸 如 此 类 。 除 了 一 个 集合 (或 者 映射 ) 之 外 ， 它 们 的 静态 工厂 
还 采用 一 个 (或 者 两 个 ) Class 对 象 。 静 态 工厂 属 于 泛 型 方法 ， 确 保 Class 对 象 和 集合 的 编译 
时 类 型 相 匹配 。 包 装 类 给 它们 所 封装 的 集合 增加 了 具体 化 。 例 如 ， 如 果 有 人 试图 将 Coin 放 - 
ER AY Collection<Stamp>, 包装 类 就 会 在 运行 时 抛 出 ClassCastException 异 常 。 用 这 些 包 
装 类 在 混 有 泛 型 和 遗留 代码 的 应 用 程序 中 追溯 “ 谁 把 错误 的 类 型 元 素 添 加 到 了 集合 中 ”很 
有 帮助 。 : 


Favorites 类 的 第 二 种 局 限 性 在 于 它 不 能 用 在 不 可 具体 化 的 (non-reifiable) 类 型 中 ( 见 第 
25 条 )。 换 句 话说 ， 你 可 以 保存 最 喜爱 的 String 或 者 String[]， 但 不 能 保存 最 喜爱 的 
List<String>。 如 果 试 图 保存 最 喜爱 的 List<String>， 程 序 就 不 能 进行 编译 。 原 因 在 于 你 无 法 
为 List<String> 获 得 一 个 Class 对 象 : List<String>.Class 是 个 语法 错误 ， 这 也 是 件 好 事 。 
List<String> 和 List<Integer> 共 用 一 个 Class 对 象 ， 即 List.class。 如 果 从 “字面 (type literal)” 
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上 来 看 ，List<String>.class 和 List<Integer>.class 是 合法 的 ， 并 返回 了 相同 的 对 象 引 用 ， 就 会 
破坏 Favorites 对 象 的 内 部 结构 。 


对 于 第 二 种 局 限 性 ， 还 没有 完全 令 人 满意 的 解决 办 法 。 有 一 种 方法 称 作 super type token, 
它 在 解决 这 一 局 限 性 方面 做 了 很 多 努力 ， 但 是 这 种 方法 仍 有 它 自身 的 局 限 性 [Gafter07]。 


Favorites 使 用 的 类 型 令 牌 (type token) 是 无 限制 的 ，getFavorite 和 putFavorite 接 受 任何 
Class 对 象 。 有 时 候 ， 可 能 需要 限制 那些 可 以 传 给 方法 的 类 型 。 这 可 以 通过 有 限制 的 类 型 令 牌 
(bounded type token) 来 实现 ， 它 只 是 一 个 类 型 令 牌 ， 利 用 有 限制 类 型 参数 ( 见 第 27 条 ) 或 
者 有 限制 通配符 〈 见 第 28 条 ) ， 来 限制 可 以 表示 的 类 型 。 


注解 API ( 见 第 35 条 ) 广泛 利用 了 有 限制 的 类 型 令 牌 。 例 如 ， 这 是 一 个 在 运行 时 读 取 注 解 
的 方法 。 这 个 方法 来 自 AnnotatedElement 接 口 ， 它 通过 表示 类 、 方 法 、 域 及 其 他 程序 元 素 的 
反射 类 型 来 实现 ， 


public <T extends Annotation> 
T getAnnotation(Class<T> annotationType) ; 


参数 annotationType 是 一 个 表示 注解 类 型 的 有 限制 的 类 型 令 牌 。 如 果 元 素 有 这 种 类 型 的 注 
解 ， 该 方法 就 将 它 返 回 ， 如 果 没 有 ， 则 返回 null。 被 注解 的 元 素 本 质 上 是 个 类 型 安全 的 异 构 容 
器 ， 容 器 的 键 属于 注解 类 型 。 


假设 你 有 一 个 类 型 Class<?> 的 对 象 ， 并 且 想 将 它 传 给 一 个 需要 有 限制 的 类 型 令 牌 的 方法 ， 
例如 getAnnotation。 你 可 以 将 对 象 转换 成 Class<? extends Annotation>， 但 是 这 种 转换 是 非 受 
检 的 ， 因 此 会 产生 一 条 编译 时 警告 ( 见 第 24 条 ) 。 幸 运 的 是 ， 类 Class 提 供 了 一 个 安全 (ABA) 
地 执行 这 种 转换 的 实例 方法 。 该 方法 称 作 asSubclass， 它 将 调用 它 的 Class 对 象 转换 成 用 其 参 
数 表示 的 类 的 一 个 子 类 。 如 果 转 换 成 功 ， 该 方法 返回 它 的 参数 ， 如 果 失 败 ， 则 抛 出 
ClassCastException 异 常 。 


以 下 示范 了 如 何 利用 asSubclass 方 法 在 编译 时 读 取 类 型 未 知 的 注解 。 这 个 方法 编译 时 没有 
出 现 错误 或 者 警告 ; 


// Use of asSubclass to safely cast to a bounded type token 
static Annotation getAnnotation(AnnotatedElement element, 
String annotationTypeName) { 
Class<?> annotationType = null; // Unbounded type token 
try { 
annotationType = Class. forName(annotationTypeName) ; 
} catch (Exception ex) { 
throw new I]legalArgumentException(ex); 


return element.getAnnotation( 
annotationType.asSubclass(Annotation.class)); 
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总 而 言 之 ， 集 合 API 说 明了 泛 型 的 一 般 用 法 ， 限 制 你 每 个 容器 只 能 有 固定 数目 的 类 型 参数 。 
你 可 以 通过 将 类 型 参数 放 在 键 上 而 不 是 容器 上 来 避 开 这 一 限制 。 对 于 这 种 类 型 安全 的 异 构 容 
器 ， 可 以 用 Class 对 象 作 为 键 。 以 这 种 方式 使 用 的 Class 对 象 称 作 类 型 令 牌 。 你 也 可 以 使 用 定制 
的 键 类 型 。 例 如 ， 用 一 个 DatabaseRow 类 型 表示 一 个 数据 库 行 (容器 ) ， 用 泛 型 Column<T> 作 
为 它 的 键 。 





第 6 章 
枚 举 和 注解 


Java 1.5 发 行 版 本 中 增加 了 两 个 新 的 引用 类 型 家 族 : 一 种 新 的 类 称 作 枚 举 类 型 (enum 
type) ， 一 种 新 的 接口 称 作 注 解 类 型 (annotation type)。 本 章 讨 论 使 用 这 两 个 新 的 类 型 家 族 
的 最 佳 实践 。 





枚 举 类 型 (enum type) 是 指 由 一 组 固定 的 常量 组 成 合法 值 的 类 型 ， 例 如 一 年 中 的 季节 、 
太阳 系 中 的 行星 或 者 一 副 牌 中 的 花色 。 在 编程 语言 中 还 没有 引入 枚 举 类 型 之 前 ， 表 示 枚 举 类 
型 的 常用 模式 是 声明 一 组 具名 的 int 常 量 ， 每 个 类 型 成 员 一 个 常量 : 


// The int enum pattern - severely deficient! 
public static final int APPLE_FUJI = 0; 
public static final int APPLE_PIPPIN = 1; 
public static final int APPLE_GRANNY_SMITH = 2; 
public static final int ORANGE_NAVEL = Q; 
public static final int ORANGE_TEMPLE = 1; 
public static final int ORANGE_BLOOD = 2; 


这 种 方法 称 作 int 枚 举 模式 (int enum pattern) ， 存 在 着 诸多 不 足 。 它 在 类 型 安全 性 和 使 用 
方便 性 方面 没有 任何 帮助 。 如 果 你 将 apple 传 到 想 要 orange 的 方法 中 ， 编 译 器 也 不 会 出 现 栎 告 ， 
还 会 用 == 操 作 符 将 apple 与 orange 进 行 对 比 ， 甚 至 更 糟糕 ; 


// Tasty citrus flavored applesauce! 
int i = (APPLE_FUJI -.ORANGE_TEMPLE) / APPLE_PIPPIN; 


注意 每 个 apple 常 量 的 名 称 都 以 APPLE_ 作 为 前 级 ， 每 个 orange 常 量 则 都 以 ORANGE_ 作 为 
前 级 。 这 是 因为 Java 没 有 为 int 枚 举 组 提供 命名 空间 。 dt Ae 
前 组 可 以 防止 名 称 发 生 冲 突 。 
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采用 int 枚 举 模式 的 程序 是 十 分 脆弱 的 。 因 为 int 枚 举 是 编译 时 常量 ， 被 编译 到 使 用 它们 的 
客户 端 中 。 如 果 与 枚 举 常量 关联 的 int 发 生 了 变化 ， 客 户 端 就 必须 重新 编译 。 如 果 没 有 重新 编 
译 ， 程 序 还 是 可 以 运行 ， 但 是 它们 的 行为 就 是 不 确定 的 。 


将 int 枚 举 常 量 翻译 成 可 打印 的 字符 串 ， 并 没有 很 便利 的 方法 。 如 果 将 这 种 常量 打印 出 来 ， 
或 者 从 调试 器 中 将 它 显 示 出 来 ， 你 所 见 到 的 就 是 一 个 数字 ， 这 没有 太 大 的 用 处 。 要 遍历 一 个 
组 中 的 所 有 int 枚 举 常量 ， 甚 至 获得 int 枚 举 组 的 大 小 ， 这 些 都 没有 很 可 靠 的 方法 。 


你 还 可 能 磁 到 这 种 模式 的 变 体 ， 在 这 种 模式 中 使 用 的 是 String 常 量 ， 而 不 是 int 常 量 。 这 样 
的 变 体 被 称 作 String 枚 举 模式 ， 同 样 也 是 我 们 最 不 期 望 的 。 虽 然 它 为 这 些 常量 提供 了 可 打印 的 
字符 串 ， 但 是 它 会 导致 性 能 问题 ， 因 为 它 依 赖 于 字符 串 的 比较 操作 。 更 精 糕 的 是 ， 它 会 导致 
初级 用 户 把 字符 串 常 量 硬 编码 到 客户 端 代码 中 ， 而 不 是 使 用 适当 的 域 (field) 名 。 如 果 这 样 
的 硬 编码 字符 串 常 量 中 包含 有 书写 错误 ， 那 么 ， 这 样 的 错误 在 编译 时 不 会 被 检测 到 ， 但 是 在 
运行 的 时 候 却 会 报错 。 


幸运 的 是 ， 从 Javal.5 发 行 版 本 开始 ， 就 提出 了 另 一 种 可 以 替代 的 解决 方案 ， 可 以 避免 int 
和 String 枚 举 模式 的 缺点 ， 并 提供 许多 额外 的 好 处 。 这 就 是 (JLS，8.9)。 下 面 以 最 简单 的 形 
式 演示 了 这 种 模式 : l 


public enum Apple { FUJI, PIPPIN, GRANNY_SMITH } 
public enum Orange { NAVEL, TEMPLE, BLOOD } 


表面 上 看 来 ， 这 些 枚 举 类 型 与 其 他 语言 中 的 没有 什么 两 样 ， 例 如 C、C++ 和 C#， 但 是 实际 
上 并 非 如 此 。Java 的 枚 举 类 型 是 功能 十 分 齐全 的 类 , 功能 比 其 他 语言 中 的 对 等 物 要 更 强大 得 多 ， 
Java 的 枚 举 本 质 上 是 int 值 。 


Java 枚 举 类 型 背后 的 基本 想法 非常 简单 ; 它们 就 是 通过 公有 的 静态 final 域 为 每 个 枚 举 常量 
导出 实例 的 类 。 因 为 没有 可 以 访问 的 构造 器 ， 枚 举 类 型 是 真正 的 final。 因 为 客户 端 既 不 能 创 
建 枚 举 类 型 的 实例 ， 也 不 能 对 它 进 行 扩展 ， 因 此 很 可 能 没有 实例 ， 而 只 有 声明 过 的 枚 举 常量 。 
换 句 话说 ， 枚 举 类 型 是 实例 受 控 的。 它们 是 单 例 (Singleton) 的 泛 型 化 ( 见 第 3 条 )， 本 质 上 
是 单元 素 的 枚 举 。 对 于 熟悉 本 书 第 一 版 的 读者 来 说 ， 枚 举 类 型 为 类 型 安全 的 枚 举 (typesafe 
enum) 模式 [Bloch01， 见 第 21 条 ] 提 供 了 语言 方面 的 支持 。 


枚 举 提 供 了 编译 时 的 类 型 安全 。 如 果 声 明 一 个 参数 的 类 型 为 Apple， 就 可 以 保证 ， 被 传 到 
该 参数 上 的 任何 非 null 的 对 象 引 用 一 定 属于 三 个 有 效 的 Apple 值 之 一 。 试 图 传递 类 型 错误 的 值 
时 ， 会 导致 编译 时 错误 ， 就 像 试 图 将 某 种 枚 举 类 型 的 表达 式 赋 给 另 一 种 枚 举 类 型 的 变量 ,或 
者 试图 利用 == 操 作 符 比较 不 同 枚 举 类 型 的 值 一 样 。 


包含 同名 常量 的 多 个 枚 举 类 型 可 以 在 一 个 系统 中 和 平 共处 ， 因 为 每 个 类 型 都 有 自己 的 命名 
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空间 。 你 可 以 增加 或 者 重新 排列 枚 举 类 型 中 的 常量 ， 而 无 需 重新 编译 它 的 客户 端 代码 ， 因 为 
导出 常量 的 域 在 枚 举 类 型 和 它 的 客户 端 之 间 提供 了 一 个 隔离 层 : 常量 值 并 没有 被 编译 到 客户 
端 代码 中 ， 而 是 在 int 枚 举 模式 之 中 。 最 终 ， 可 以 通过 调用 toString 方 法 ， 将 枚 举 转换 成 可 打印 
的 字符 串 。 


除了 完善 了 int 枚 举 模式 的 不 足 之 外 ， 枚 举 类 型 还 允许 添加 任意 的 方法 和 域 ， 并 实现 任意 
的 接口 。 它 们 提供 了 所 有 Object 方法 ( 见 第 3 章 ) 的 高 级 实现 ， 实 现 了 Comparable ( 见 第 12 条 ) 
和 Serializable 接 口 〈 见 第 11 章 ) ， 并 针对 权 举 类 型 的 可 任意 改变 性 设计 了 序列 化 方式 。 


那么 我 们 为 什么 要 将 方法 或 者 域 添加 到 枚 举 类 型 中 呢 ? 首先 ， 你 可 能 是 想 将 数据 与 它 的 党 
量 关联 起 来 。 例 如 ， 一 个 能 够 返回 水 果 颜 色 或 者 返回 水 果 图 片 的 方法 ， 对 于 我 们 的 Apple 和 
Orange 类 型 来 说 可 能 很 有 好 处 。 你 可 以 利用 任何 适当 的 方法 来 增强 枚 举 类 型 。 枚 举 类 型 可 以 
先 作 为 枚 举 常量 的 一 个 简单 集合 ， 随 着 时 间 的 推移 再 演变 成 为 全 功能 的 抽象 。 


举 个 有 关 枚 举 类 型 的 好 例子 ， 比 如 太阳 系 中 的 8 颗 行星 。 每 颗 行 星 都 有 质量 和 半径 ， 通 过 
这 两 个 属性 可 以 计算 出 它 的 表面 重力 。 从 而 给 定 物体 的 质量 ， 就 可 以 计算 出 一 个 物体 在 行星 
表面 上 的 重量 。 下 面 就 是 这 个 枚 举 。 每 个 枚 举 常量 后 面 括号 中 的 数值 就 是 传递 给 构造 器 的 参 
数 。 在 这 个 例子 中 ， 它 们 就 是 行星 的 质量 和 半径 : 


// Enum type with data and behavior 
public enum Planet { 
MERCURY(3.302e+23，2.439e6) ， 
VENUS (4.869e+24, 6.052e6), 
EARTH (5.975e+24, 6.378e6), 
MARS (6.419e+23, 3.393e6),. 
JUPITER(1.899e+27, 7.149e7), 
SATURN (5.685e+26, 6.027e7), 
URANUS (8.683e+25, 2.556e7), 
NEPTUNE(1.024e+26, 2.477e7); 
private final double mass; // In kilograms 
private final double radius; // In meters 
private final double surfaceGravity; // In m / sA2 


// Universal gravitational constant in mA3 / kg sA2 
private static final double G = 6.67300E-11; 


// Constructor 
Planet(double mass, double radius) { 
this.mass = mass; 
this.radius = radius; 
surfaceGravity = G « mass / (radius « radius); 


public double mass() { return mass; } 
public double radius() { return radius; } 
public double surfaceGravity() { return surfaceGravity; } 


public double surfaceWeight(double mass) { 
return mass * surfaceGravity; // F = ma 
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编写 一 个 像 Planet 这 样 的 枚 举 类 型 并 不 难 。 为 了 将 数据 与 枚 举 常 量 关 联 起 来 ， 得 声明 实例 
域 ， 并 编写 一 个 带 有 数据 并 将 数据 保存 在 域 中 的 构造 器 。 枚 举 天 生 就 是 不 可 变 的 ， 因 此 所 有 
的 域 都 应 该 为 final 的 〈 见 第 15 条 ) 。 它 们 可 以 是 公有 的 ， 但 最 好 将 它们 做 成 是 私有 的 ， 并 提供 
公有 的 访问 方法 ( 见 第 14 条 )。 在 Planet 这 个 示例 中 ， 构 造 器 还 计算 和 保存 表面 重力 ; 但 这 正 
是 一 种 优化 。 每 当 surfaceWeight 方 法 用 到 重力 时 ， 都 会 根据 质量 和 半径 重新 计算 ， 并 返回 它 
在 该 常量 所 表示 的 行星 上 的 重量 。 


虽然 Planet 枚 举 很 简单 ， 它 的 功能 却 强 大 得 出 奇 。 下 面 是 一 个 简短 的 程序 ， 根 据 某 个 物体 
在 地 球 上 的 重量 (以 任何 单位 ), 打印 出 一 张 很 棒 的 表格 ， 显示 出 该 物体 在 所 有 8 颗 行 星 上 的 
重量 (用 相同 的 单位 ): 


public class WeightTable { 
public static void main(String[] args) { 
double earthWeight = Double.parseDouble(args[@]); 
double mass = earthWeight / Planet.EARTH.surfaceGravity(); 
for (Planet p : Planet.valuesQ) 
System.out.printf("Weight on %s is %f%n", 
p, p.surfaceWeight(mass)); 
} 
} 


注意 Planet 就 像 所 有 的 枚 举 一 样 ， 它 有 一 个 静态 的 values 方 法 ， 按 照 声明 顺序 返回 它 的 值 
数组 。 还 要 注意 toString 方 法 返回 每 个 枚 举 值 的 声明 名 称 ， 使 得 println 和 printf 的 打印 变 得 更 加 
容易 。 如 果 你 不 满意 这 种 字符 串 表 示 法 ， 可 以 通过 覆盖 toString 方 法 对 它 进 行 修改 。 下 面 就 是 
用 命令 行 参 数 175 运 行 这 个 小 小 的 WeightTable 程 序 时 的 结果 : 

Weight on MERCURY is 66.133672 

Weight on VENUS is 158.383926 

Weight on EARTH is 175.000000 

Weight on MARS is 66.430699 

Weight on JUPITER is 442.693902 

Weight on SATURN is 186.464970 

Weight on URANUS is 158.349709 

Weight on NEPTUNE is 198.846116 


如 果 这 是 你 第 一 次 在 实践 中 见 到 Java 的 printf 方 法 ， ee 你 在 这 里 用 
的 是 %n， 在 C 中 则 用 \n。 


与 枚 举 常 量 关联 的 有 些 行为 ， 可 能 只 需要 用 在 定义 了 枚 举 的 类 或 者 包 中 。 这 种 行为 最 好 被 
实现 成 私有 的 或 者 包 级 私有 的 方法 。 于 是 ， 每 个 枚 举 常 量 都 带 有 一 组 隐蔽 的 行为 ， 这 使 得 包 
含 该 枚 举 的 类 或 者 包 在 遇 到 这 种 常量 时 都 可 以 做 出 适当 的 反应 。 就 像 其 他 的 类 一 样 ， 除 非 迫 
不 得 已 要 将 枚 举 方法 导出 至 它 的 客户 端 ， 否 则 都 应 该 将 它 声明 为 私有 的 ， 如 有 必要 ， 则 声明 
为 包 级 私有 的 ( 见 第 13 条 )。 


如 果 一 个 枚 举 具有 普遍 适用 性 ， 它 就 应 该 成 为 一 个 顶层 类 (top-level class) ; 如果 它 只 
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是 被 用 在 一 个 特定 的 顶层 类 中 ， 它 就 应 该 成 为 该 顶层 类 的 一 个 成 员 类 ( 见 第 22 条 )。 例 如 ， 
java.math.RoundingMode 枚 举 表示 十 进 制 小 数 的 舍 人 模式 (rounding mode)。 这 些 舍 人 模式 
用 于 BigDecimal 类 ， 但 是 它们 提供 了 一 个 非常 有 用 的 抽象 ， 这 种 抽象 本 质 上 又 不 属于 
BigDecimal 类 。 通 过 使 RoundingMode 变 成 一 个 顶层 类 ， 库 的 设计 者 鼓励 任何 需要 伟人 模式 的 
程序 员 重 用 这 个 枚 举 ， 从 而 增强 API 之 间 的 一 致 性 。 


Planet 示 例 中 所 示 的 方法 对 于 大 多 数 枚 举 类 型 来 说 就 足够 了 ， 但 你 有 时 候 会 需要 更 多 的 方 
法 。 每 个 Planet 常 量 都 关联 了 不 同 的 数据 ， 但 你 有 时 需要 将 本 质 上 不 同 的 行为 (behavior) 与 . 
每 个 常量 关联 起 来 。 例 如 ， 假 设 你 在 编写 一 个 枚 举 类 型 ， 来 表示 计算 器 的 四 大 基本 操作 (HN 
加 减 乘除 ) ， 你 想 要 提供 一 个 方法 来 执行 每 个 常量 所 表示 的 算术 运算 。 有 一 种 方法 是 通过 启用 
枚 举 的 值 来 实现 : 

// Enum type that switches on its own value - questionable 

public enum Operation { 

PLUS, MINUS, TIMES, DIVIDE; 
// Do the arithmetic op represented by this constant 
double apply(double x, double y) { 
: switch(this) { 
case PLUS: return x + y; 
case MINUS: return x - y; 
case TIMES: return x « y; 
case DIVIDE: return x / y; 
throw new AssertionError("Unknown op: " + this); 


} 


这 段 代 码 可 行 ， 但 是 不 太 好 看 。 如 果 没 有 throw 语 句 ， 它 就 不 能 进行 编译 ， 虽 然 从 技术 角 
度 来 看 代码 的 结束 部 分 是 可 以 执行 到 的 ， 但 是 实际 上 是 不 可 能 执行 到 这 行 代码 的 [JILS， 
14.2.1]。 更 糟糕 的 是 ， 这 段 代 码 很 脆弱 。 如 果 你 添加 了 新 的 枚 举 常量 ， 却 忘记 给 switch 添 加 相 
应 的 条 件 ， 枚 举 仍然 可 以 编译 ， 但 是 当 你 试图 运用 新 的 运算 时 ， 就 会 运行 失败 。 


幸运 的 是 ， 有 一 种 更 好 的 方法 可 以 将 不 同 的 行为 与 每 个 枚 举 常 量 关 联 起 来 : 在 枚 举 类 型 中 
声明 一 个 抽象 的 apply 方 法 ， 并 在 特定 于 常量 的 类 主体 (constant-specific class body) H, JH 
具体 的 方法 覆盖 每 个 常量 的 抽象 apply 方 法 。 这 种 方法 被 称 作 特 定 于 常量 的 方法 实现 
(constant-specific method implementation ) : 

// Enum type with constant-specific method implementations 

public enum Operation { 

PLUS { double apply(double x, double y){return x + 
MINUS { double apply(double x, double y){réturn x - 
TIMES { double apply(double x, double y){return x « 
DIVIDE { double apply(double x, double y){return x / 


abstract double apply(double x, double y); 
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如 果 给 Operation 的 第 二 种 版 本 添加 新 的 常量 ， 你 就 不 可 能 会 忘记 提供 apply 方 法 ， 因 为 该 
方法 就 紧 跟 在 每 个 常量 声明 之 后 。 即 使 你 真 的 忘记 了 ， 编 译 器 也 会 提醒 你 ， 因 为 枚 举 类 型 中 
的 抽象 方法 必须 被 它 所 有 常量 中 的 具体 方法 所 覆盖 。 


特定 于 常量 的 方法 实现 可 以 与 特定 于 常量 的 数据 结合 起 来 。 例 如 ， 下 面 的 Operation 和 覆盖 
了 了 toString 来 返回 通常 与 该 操作 关联 的 符号 : 


// Enum type with constant-specific class bodies and data 
public enum Operation { 
PLUS("+") { 
double apply(double x, double y) { return x + y; } 


}, 
MINUS("-") { 
double apply(double x, double y) { return x - y; } 


Ke 
TIMES("«") { 

double apply(double x, double y) { return x * y; } 
}, 
DIVIDE("/") { 

double apply(double x, double y) { return x / y; } 
J; 
private final String symbol; 


Operation(String symbol) { this.symbol = symbol; } 
@Override public String toString { return symbol; } 


abstract double apply(double x, double y); 
} 


在 有 些 情况 下 ， 在 枚 举 中 覆盖 toString 非 常 有 用 。 例 如， 上 述 的 toString 实 现 使 得 打印 算术 
表达 式 变 得 非常 容易 ， 如 这 段 小 程序 所 示 : 


public static void main(String[] args) { 
double x = Double.parseDouble(args[@]); 
double y = Double.parseDouble(args[1]); 
for (Operation op : Operation.values()) 
System.out.printf("%f %s %f = %f%n", 
) x, Op, y, op.apply(x, y)); 


用 2 和 4 作为 命令 行 参数 运行 这 段 程序 ， 会 输出 : 


2.000000 + 4.000000 = 6.000000 
2.000000 - 4.000000 = -2.000000 
2.000000 « 4.000000 = 8.000000 
2.000008 / 4.000000 = 0.500000 


枚 举 类 型 有 一 个 自动 产生 的 valueOf(String) 方 法 ， 它 将 常量 的 名 字 转 变 成 常量 本 身 。 如 果 
在 枚 举 类 型 中 覆盖 toString ， 要 考虑 编写 一 个 fromString 方 法 ， 将 定制 的 字符 串 表 示 法 变 回 相 
应 的 枚 举 。 下 列 代码 (适当 地 改变 了 类 型 名 称 ) 可 以 为 任何 枚 举 完 成 这 一 技巧 ， 只 要 每 个 常 
量 都 有 一 个 独特 的 字符 串 表 示 法 : 
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// Implementing a fromString method on an enum type 
private static final Map<String, Operation> stringToEnum 
= new HashMap<String, Operation>(); 
static { // Initialize map from constant name to enum constant 
for (Operation op : values()) 
stringToEnum.put(op.toString(), op); 


// Returns Operation for string, or null if string is invalid 


public static Operation fromString(String symbol) { 
return stringToEnum.get (symbol); 


注意 ， 在 常量 被 创建 之 后 ，Operation 常 量 从 静态 代码 块 中 被 放 人 到 了 stringToEnum 的 
map 中 。 试 图 使 每 个 常量 都 从 自己 的 构造 器 将 自身 放 入 到 map 中 ， 会 导致 编译 时 错误 。 这 是 好 
事 ， 因 为 如 果 这 是 合法 的 ， 就 会 抛 出 NullPointerException 异 常 。 枚 举 构 造 器 不 可 以 访问 枚 举 
的 静态 域 ， 除 了 编译 时 常量 域 之 外 。 这 一 限制 是 有 必要 的 ， 因 为 构造 器 运行 的 上 时候， 这 些 静 
态 域 还 没有 被 初始 化 。 


特定 于 常量 的 方法 实现 有 一 个 美中不足 的 地 方 ， 它 们 使 得 在 枚 举 常量 中 共享 代码 变 得 更 加 
困难 了 。 例 如 ， 考 虑 用 一 个 枚 举 表 示 薪 资 包 中 的 工作 天 数 。 这 个 枚 举 有 一 个 方法 ， 根 据 给 定 
某 工人 的 基本 工资 ( 按 小 时 ) 以 及 当天 的 工作 时 间 ， 来 计算 他 当天 的 报酬 。 在 五 个 工作 日 中 ， 
超过 正常 八 小 时 的 工作 时 间 都 会 产生 加 班 工资 ;在 双休日 中 ,所 有 工作 都 产生 加 班 工资 。 利 
用 switch 语 句 ， 很 容易 通过 将 多 个 case 标 签 分 别 应 用 到 两 个 代码 片断 中 ， 来 完成 这 一 计算 。 为 
了 简洁 起 见 ， 这 个 示例 中 的 代码 使 用 了 double， 但 是 注意 double 并 不 是 适合 薪资 应 用 程序 ( 见 
第 48 条 ) 的 数据 类 型 。 


// Enum that switches on its value to share code - questionable 
enum PayrollDay { 
MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, 
SATURDAY, SUNDAY; 
private static final int HOURS_PER_SHIFT = 8; 
double pay(double hoursWorked, double payRate) { 
double basePay = hoursWorked * payRate; 


double overtimePay; // Calculate overtime pay 
switch(this) { 
case SATURDAY: case SUNDAY: 
overtimePay = hoursWorked * payRate / 2; 
default: // Weekdays 
overtimePay = hoursWorked <= HOURS_PER_SHIFT ? 
@ : ChoursWorked - HOURS_PER_SHIFT) + payRate / 2; 
break; 


return basePay + overtimePay; 
} 
} 


不 可 否认 ， 这 段 代 码 十 分 简洁 ， 但 是 从 维护 的 角度 来 看 ， 它 非常 危险 。 假 设 将 一 个 元 素 添 
加 到 该 枚 举 中 ,或许 是 一 个 表示 假期 天 数 的 特殊 值 ， 但 是 忘记 给 switch 语 句 添加 相应 的 case。. 
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程序 依然 可 以 编译 ， 但 pay 方 法 会 悄悄 地 将 假期 的 工资 计算 成 与 正常 工作 日 的 相同 。 


为 了 利用 特定 于 常量 的 方法 实现 安全 地 执行 工资 计算 ， 你 可 能 必须 重复 计算 每 个 常量 的 加 
班 工资 ,或 者 将 计算 移 到 两 个 辅助 方法 中 (一 个 用 来 计算 工作 日 ， 一 个 用 来 计算 双休日 ), 并 
从 每 个 常量 调用 相应 的 辅助 方法 。 这 任何 一 种 方法 都 会 产生 相当 数量 的 样板 代码 ， 结 果 降 低 
了 可 读 性 ， 并 增加 了 出 错 的 机 率 。 


通过 用 计算 工作 日 加 班 工资 的 具体 方法 代替 PayrollDay 中 抽象 的 overtimePay 方 法 ， 可 以 
减少 样板 代码 。 这 样 ， 就 只 有 双休日 必须 覆盖 该 方法 了 。 但 是 这 样 也 有 着 与 Switch 语句 一 样 的 
ARE: 如 果 又 增加 了 一 天 而 没有 覆盖 overtimePay 方 法 ， 就 会 悄悄 地 延续 工作 日 的 计算 。 


你 真正 想 要 的 就 是 每 当 添 加 一 个 枚 举 常 量 时 ， 就 强制 选择 一 种 加 班 报酬 策略 。 幸 运 的 是 ， 
有 一 种 很 好 的 方法 可 以 实现 这 一 点 。 这 种 想法 就 是 将 加 班 工资 计算 移 到 一 个 私有 的 贬 套 枚 举 中 ， 
将 这 个 策略 枚 举 (strategy enum) 的 实例 传 到 PayrollDay 枚 举 的 构造 器 中 。 之 后 PayrollDay 枚 
举 将 加 班 工资 计算 委托 给 策略 枚 举 ，PayrollDay 中 就 不 需要 switch 语 句 或 者 特定 于 常量 的 方法 
实现 了 。 虽 然 这 种 模式 没有 switch 语 句 那么 简洁 ， 但 更 加 安全 ， 也 更 加 灵活 : 


// The strategy enum pattern 

enum Payro11Day { 
MONDAY (PayType.WEEKDAY) ，TUESDAY(CPayType.WEEKDAY) , 
WEDNESDAY (PayType.WEEKDAY) , THURSDAY(PayType.WEEKDAY) , 
FRIDAY (PayType.WEEKDAY) , 
SATURDAY (PayType.WEEKEND) , SUNDAY(PayType. WEEKEND) ; 


private final PayType payType; 
PayrollDay(PayType payType) { this.payType = payType; } 


double pay(double hoursWorked, double payRate) { 
return payType.pay(hoursWorked, payRate); 
} 


// The strategy enum type 
private enum PayType { 
WEEKDAY { 
double overtimePay(double hours, double payRate) { 
return hours <= HOURS_PER_SHIFT ? 0 : 
(hours - HOURS_PER_SHIFT) * payRate / 2; 


}, 
WEEKEND { 
double overtimePay(double hours, double payRate) { 
return hours + payRate / 2; 


}; 

_ private static final int HOURS_PER_SHIFT = 8; 
abstract double overtimePay(double hrs, double payRate); 
double pay(double hoursWorked, double payRate) { 


double basePay = hoursWorked * payRate; 
return basePay + overtimePay(hoursWorked, payRate); 
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如 果 枚 举 中 的 Switch 语句 不 是 在 枚 举 中 实现 特定 于 常量 的 行为 的 一 种 很 好 的 选择 ， 那 么 它 
们 还 有 什么 用 处 呢 ? 和 枚 举 中 的 Switch 语 向 适合 于 给 外 部 的 枚 举 类 型 增加 特定 于 常量 的 行为 。 例 
如 ， 假 设 Operation 枚 举 不 受 你 的 控制 ， 你 希望 它 有 一 个 实例 方法 来 返回 每 个 运算 的 反 运 算 。 
你 可 以 用 下 列 静态 方法 模拟 这 种 效果 : 

// Switch on an enum to simulate a missing method 

public static Operation inverse(Operation op) { 

switch(op) { 
case PLUS: return Operation.MINUS; 
case MINUS: return Operation. PLUS; 
case TIMES: return Operation.DIVIDE; 
case DIVIDE: return Operation. TIMES; 
default: throw new AssertionError("Unknown op: " + op); 


} 


一 般 来 说 ， 枚 举 会 优先 使 用 comparable 而 非 int 常 量 。 与 int 常 量 相 比 ， 枚 举 有 个 小 小 的 性 
能 缺点 ， 即 装载 和 初始 化 枚 举 时 会 有 空间 和 时 间 的 成 本 。 除 了 受 资源 约束 的 设备 ， 例 如 手机 
和 烤 面 包机 之 外 ， 在 实践 中 不 必 太 在 意 这 个 问题 。 


那么 什么 时 候 应 该 使 用 枚 举 呢 ? 每 当 需 要 一 组 固定 常量 的 时 候 。 当 然 ， 这 包括 “天 然 的 枚 
举 类 型 ”， 例 如 行星 、 一 周 的 天 数 以 及 棋子 的 数目 等 等 。 但 它 也 包括 你 在 编译 时 就 知道 其 所 有 
可 能 值 的 其 他 集合 ， 例 如 菜单 的 选项 、 操 作 代 码 以 及 命令 行 标记 等 。 枚 举 类 型 中 的 常量 集 并 
不 一 定 要 始终 保持 不 变 。 专 门 设计 枚 举 特 性 是 考虑 到 枚 举 类 型 的 二 进 制 兼容 演变 。 


总 而 言 之 ， 与 int 常 量 相 比 ， 枚 举 类 型 的 优势 是 不 言 而 喻 的 : 枚 举 要 易 读 得 多 ， 也 更 加 安 
全 ， 功 能 更 加 强大 。 许 多 枚 举 都 不 需要 显 式 的 构造 器 或 者 成 员 ， 但 许多 其 他 枚 举 则 受益 于 
“每 个 常量 与 属性 的 关联 ”以 及 “提供 行为 受 这 个 属性 影响 的 方法 ”。 只 有 极 少 数 的 枚 举 受益 
于 将 多 种 行为 与 单个 方法 关联 。 在 这 种 相对 少见 的 情况 下 ， 特 定 于 常量 的 方法 要 优先 于 启用 
自 有 值 的 枚 举 。 如 果 多 个 枚 举 常 量 同 时 共享 相同 的 行为 ， 则 考虑 策略 枚 举 。 
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许多 枚 举 天 生 就 与 一 个 单独 的 int 值 相关 联 。 所 有 的 枚 举 都 有 一 个 ordinal 方 法 ， 它 返回 每 
个 枚 举 常 量 在 类 型 中 的 数字 位 置 。 你 可 以 试 着 从 序数 中 得 到 关联 的 int 值 : 
// Abuse of ordinal to derive an associated value - DON'T Do THIS 
public enum Ensemble { 
， DUET, TRIO, QUARTET, QUINTET, 
SEXTET, SEPTET, OCTET, NONET, DECTET; 


public int numberOfMusicians() { return ordinal() + 1; } 


虽然 这 个 枚 举 不 错 ， 但 是 维护 起 来 就 像 一 场 恶 梦 。 如 果 常 量 进行 重新 排序 ，numberOf- 
Musicians 方 法 就 会 遭 到 破坏 。 如 果 要 再 添加 一 个 与 已 经 用 过 的 int 值 关联 的 枚 举 常 量 ， 就 没 那 
么 走运 了 。 例 如 ， 给 双 四 重奏 (double quartet) 添加 一 个 常量 ， 它 就 像 个 八重 奏 一 样 ， 是 由 
8 位 演奏 家 组 成 ， 但 是 没有 办 法 做 到 。 


要 是 没有 给 所 有 这 些 int 值 添加 常量 ， 也 无 法 给 某 个 int 值 添加 常量 。 例 如 ， 假 设想 要 添加 
一 个 常量 表示 三 四 重奏 (triple quartet), ， 它 由 12 位 演奏 家 组 成 。 对 于 由 11 位 演奏 家 组 成 的 合 
奏 曲 并 没有 标准 的 术语 ， 因 此 只 好 给 没有 用 过 的 int 值 (11) 添加 一 个 虚拟 (dummy) 常量 。 
这 么 做 顶 多 就 是 不 太 好 看 。 如 果 有 许多 int 值 都 是 从 未 用 过 的 ， 可 就 不 切实 际 了 。 


幸运 的 是 ， 有 一 种 很 简单 的 方法 可 以 解决 这 些 问 题 。 永 远 不 要 根据 枚 举 的 序数 导出 与 它 关 
联 的 值 ， 而 是 要 将 它 保存 在 一 个 实例 域 中 : 
public enum Ensemble { 
SOLO(1), DUET(2), TRIOC3), QUARTET(4), QUINTET(S), 
SEXTET(6), SEPTET(7), OCTET(8), DOUBLE_QUARTET(8), 
NONET(9), DECTET(10), TRIPLE_QUARTET(12); 
private final int numberOfMusicians; 
Ensemble(int size) { this.numberOfMusicians = size; } 
$ public int numberOfMusicians() { return numberOfMusicians; } 
Enum 规 范 中 谈 到 ordinal 时 这 么 写 道 :“ 大 多 数 程序 员 都 不 需要 这 个 方法 。 它 是 设计 成 用 
于 像 EnumSet 和 EnumMap 这 种 基于 枚 举 的 通用 数据 结构 的 。 除非 你 在 编写 的 是 这 种 数据 结构 ， 


否则 最 好 完全 避免 使 用 ordinal 方 法 。 
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如 果 一 个 枚 举 类 型 的 元 素 主要 用 在 集合 中 ， 一 般 就 使 用 int 枚 举 模 式 ( 见 第 30 条 )， 将 2 的 
不 同 倍数 赋予 每 个 常量 : 


// Bit field enumeration constants - OBSOLETE! 

public class Text { 
public static final int STYLE_BOLD ey ee Shit: 
public static final int STYLE_ITALIC = 3-94:13 ff 
public static final int STYLE UNDERLINE wi Re 
public static final int STYLE_STRIKETHROUGH = 1 << 3; // 8 


// Parameter is bitwise OR of zero or more STYLE_ constants 
public void applyStyles(int styles) { ... } 
} 


这 种 表示 法 让 你 用 OR 位 运算 将 几 个 常量 合并 到 一 个 集合 中 ， 称 作 位 域 (bit field): 


text.applyStyles(STYLE_BOLD | STYLE_ITALIC); 


位 域 表 示 法 也 允许 利用 位 操作 ， 有 效 地 执行 像 union (联合 ) 和 intersection (交集 ) 这 样 
的 集合 操作 。 但 位 域 有 着 int 枚 举 常量 的 所 有 缺点 ， 甚 至 更 多 。 当 位 域 以 数字 形式 打印 时 ， 翻 
译 位 域 比 翻译 简单 的 int 枚 举 常量 要 困难 得 多 。 甚 至 ， 要 遍历 位 域 表 示 的 所 有 元 素 也 没有 很 容 
易 的 方法 。 i 


有 些 程序 员 优先 使 用 枚 举 而 非 int 常 量 ， 他 们 在 需要 传递 多 组 常量 集 时 ， 仍 然 倾 向 于 使 用 
位 域 。 其 实 没 有 理由 这 么 做 ， 因 为 还 有 更 好 的 替代 方法 。java.util 包 提供 了 EnumSet 类 来 有 效 
地 表示 从 单个 枚 举 类 型 中 提取 的 多 个 值 的 多 个 集合 。 这 个 类 实现 Set 接 口 ， 提 供 了 丰富 的 功能 、 
类 型 安全 性 ， 以 及 可 以 从 任何 其 他 Set 实 现 中 得 到 的 互 用 性 。 但 是 在 内 部 具体 的 实现 上 ， 每 个 
EnumSet 内 容 都 表示 为 位 矢量 。 如 果 底 层 的 枚 举 类 型 有 64 个 或 者 更 少 的 元 素 一 一 大 多 如 此 一 一 
整个 EnumSet 就 是 用 单个 long 来 表示 ， 因 此 它 的 性 能 比 得 土 位 域 的 性 能 。 批 处 理 ， 如 
removeAll 和 retainAll， 都 是 利用 位 算法 来 实现 的 ， 就 像 手工 蔡 位 域 实现 得 那样 。 但 是 可 以 避 
免 手 工 位 操作 时 容易 出 现 的 错误 以 及 不 太 雅 观 的 代码 ， 因 为 EnumSet 替 你 完成 了 这 项 艰巨 的 
E 


下 面 是 前 一 个 范例 改 成 用 枚 举 代 替 位 域 后 的 代码 ， 它 更 加 简短 、 更 加 清楚 ， 也 更 加 安全 : 


// EnumSet - a modern replacement for bit fields 
public class Text { 
public enum Style { BOLD, ITALIC, UNDERLINE, STRIKETHROUGH } 


// Any Set could be passed in, but EnumSet is clearly best 
public void applyStyles(Set<Style> styles) { ... } 
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下 面 是 将 EnumSet 实 例 传递 给 applyStyles 方 法 的 客户 端 代码 。EnumSet 提 供 了 丰富 的 静态 
工厂 来 轻松 创建 集合 ， 其 中 一 个 如 这 个 代码 所 示 : 


text.applyStyles(EnumSet.of(Style.BOLD, Style.ITALIC)) 


注意 applyStyles 方 法 采用 的 是 Set<Style> 而 非 EnumSet<Style>。 虽 然 看 起 来 好 像 所 有 的 客 
户 端 都 可 以 将 EnumSet 传 到 这 个 方法 ， 但 是 最 好 还 是 接受 接口 类 型 而 非 接受 实现 类 型 。 这 是 考 
虑 到 可 能 会 有 特殊 的 客户 端 要 传递 一 些 其 他 的 Set 实 现 ， 并 且 没 有 什么 明显 的 缺点 。 


总 而 言 之 ， 正 是 因为 枚 举 类 型 要 用 在 集合 (Set) 中 ， 所 以 没有 理由 用 位 域 来 表示 它 。 
EnumSet 类 集 位 域 的 简洁 和 性 能 优势 及 第 30 条 中 所 述 的 枚 举 类 型 的 所 有 优点 于 一 身 。 实 际 上 
EnumSet 有 个 缺点 ， 即 截止 Java 1.6 发 行 版 本 ， 它 都 无 法 创建 不 可 变 的 EnumSet， 但 是 这 一 点 
很 可 能 在 即将 出 来 的 版 本 中 得 到 修正 。 同 时 ， 可 以 用 Collections.unmodifiableSet 将 EnumSet 
封装 起 来 ， 但 是 简洁 性 和 性 能 会 受到 影响 。 
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有 时 候 ， 你 可 能 会 见 到 利用 ordinal 方 法 ( 见 第 31 条 ) 来 索引 数组 的 代码 。 例 如 下 面 这 个 
过 于 简化 的 类 ， 用 来 表示 一 种 烹饪 用 的 香草 : 


public class Herb { 
public enum Type { ANNUAL, PERENNIAL, BIENNIAL } 


private final String name; 
private final Type type; 


Herb(String name, Type type) i 


this.name = name; 
this.type = type; 


@Override public String toString( { 
return name; 


} 


现在 假设 有 一 个 香草 的 数组 ， 表 示 一 座 花 园 中 的 植物 ， 你 想 要 按照 类 型 (一 年 生 、 多 年 生 
人 如 果 要 这 么 做 的 话 ， 需 要 构建 三 个 集合 
每 种 类 型 一 个 ， 并 且 遍 历 整 座 花园 ， 将 每 种 香草 放 到 相应 的 集合 中 。 有 些 程序 员 会 将 这 些 集 
fil EEA y iag me h o 点 。 

// Using ordinal O) to index an array - DON'T DO THIS! 

Herb[] garden = ... 

Set<Herb>[] herbsByType = // Indexed by Herb.Type.ordinalQ 

(Set<Herb>[]) new Set[(Herb.Type.values(). length]; 
for (int i = 0; i < herbsByType.length; i++) 
herbsByType[i] = new HashSet<Herb>(); 


for (Herb h : garden) 
herbsByType[h. type.ordinal ()] .add(h); 


// Print the results 
for (int i = 0; i < herbsByType.length; i++) { 


System.out.printf("%s: %s%n", 
Herb.Type.values() [i], herbsByType[i]); 
} 


这 种 方法 的 确 可 行 ， 但 是 隐藏 着 许多 问题 。 因 为 数组 不 能 与 泛 型 ( 见 第 25 条 ) 兼容 ， 程 
序 需要 进行 未 受 检 的 转换 ， 并 且 不 能 正确 无 误 地 进行 编译 。 因 为 数组 不 知道 它 的 索引 代表 着 
什么 ， 你 必须 手工 标注 (label) 这 些 索引 的 输出 。 但 是 这 种 方法 最 严重 的 问题 在 于 ， 当 你 访 
问 一 个 按照 枚 举 的 序数 进行 索引 的 数组 时 ， 使 用 正确 的 int 值 就 是 你 的 职责 了 ，int 不 能 提供 枚 
举 的 类 型 安全 。 你 如 果 使 用 了 错误 的 值 ， 程序 就 会 悄悄 地 完成 错误 的 工作 ， 或 者 幸运 的 话 ， 
A Hh tH ArrayIndexOutOfBoundException E% . 
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幸运 的 是 , 有 一 种 更 好 的 方法 可 以 达到 同样 的 效果 。 数组 实际 上 充当 着 从 枚 举 到 值 的 映射 ， 
因此 可 能 还 要 用 到 Map 。 更 具体 地 说 ， 有 一 种 非常 快速 的 Map 实 现 专门 用 于 枚 举 键 PTE 
java.util.EnumMap。 以 下 就 是 用 EnumMap 改 写 后 的 程序 : 
// Using an EnumMap to associate data with an enum 
Map<Herb.Type, Set<Herb>> herbsByType = 
new EnumMap<Herb.Type, Set<Herb>>(Herb.Type.class); 
for (Herb.Type t : Herb.Type.values()) 
herbsByType.put(t, new HashSet<Herb>()); 
for (Herb h : garden) 


herbsByType.get(h. type) .add(h) ; 
System.out.printin(herbsByType) ; 


这 段 程序 更 简短 、 更 清楚 ， 也 更 加 安全 ， 运 行 速度 方面 可 以 与 使 用 序数 的 程序 相 媲 美 。 
它 没 有 不 安全 的 转换 ， 不 必 手 工 标注 这 些 索 引 的 输出 ， 因 为 映射 键 知道 如 何 将 自身 翻译 成 可 
打印 字符 串 的 枚 举 ， 计算 数组 索引 时 也 不 可 能 出 错 。EnumMap 在 运行 速度 方面 之 所 以 能 与 
通过 序数 索引 的 数组 相 媲 美 ， 是 因为 EnuMap 在 内 部 使 用 了 这 种 数组 。 但 是 它 对 程序 员 隐 藏 
了 这 种 实现 细节 ， 集 Map 的 丰富 功能 和 类 型 安全 与 数组 的 快速 于 一 身 。 注 意 EnumMap 构 造 器 
采用 键 类 型 的 Class 对 象 : 这 是 一 个 有 限制 的 类 型 令 牌 (bounded type token) ， 它 提供 了 运 
行 时 的 泛 型 信息 ( 见 第 29 条 )。 


你 还 可 能 见 到 按照 序数 进行 索引 (两 次 ) 的 数组 的 数组 ， 该 序数 表示 两 个 枚 举 值 的 映射 。 
例如 ， 下 面 这 个 程序 就 是 使 用 这 样 一 个 数组 将 两 个 阶段 映射 到 一 个 阶段 过 渡 中 〈 从 液体 到 固 
体 称 作 凝固 ， 从 液体 到 气体 称 作 沸腾 ， 诸 如 此 类 )。 


// Using ordinal() to index array of arrays - DON'T DO THIS! 
public enum Phase { SOLID, LIQUID, GAS; 
public enum Transition { 
MELT, FREEZE, BOIL, CONDENSE, SUBLIME, DEPOSIT; 
// Rows indexed by src-ordinal, cols by dst-ordinal 
private static final Transition[][] TRANSITIONS = { 
{ null, MELT, SUBLIME }, 
{ FREEZE, null, BOIL 5 
{ DEPOSIT, CONDENSE, null } 


// Returns the phase transition from one phase to another 
public static Transition from(Phase src, Phase dst) { 
return TRANSITIONS[src.ordinal()][dst.ordinal()]; 


} 
} 
这 段 程序 可 行 ， 看 起 来 也 比较 优雅 ， 但 是 事实 并 非 如 此 。 就 像 上 面 那个 比较 简单 的 香草 花 
园 的 示例 一 样 ， 编 译 器 无 法 知道 序数 和 数组 索引 之 间 的 关系 。 如 果 在 过 渡 表 中 出 了 错 ， 或 者 在 
修改 Phase 或 者 Phase.Transition 枚 举 类 型 的 时 候 忘 记 将 它 更 新 ， 程 序 就 会 在 运行 时 失败 。 这 种 
失败 的 形式 可 能 为 ArrayIndexOutOfBoundsException、NullPointerException 或 者 (更 糟糕 的 是 ) 
没有 任何 提示 的 错误 行为 。 这 张 表 的 大 小 是 阶段 个 数 的 平方 ， 即 使 非 null 项 的 数量 比较 少 。 
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同样 ， 利 用 EnumMap 依 然 可 以 做 得 更 好 一 些 。 因 为 每 个 阶段 过 渡 都 是 通过 一 对 阶段 枚 举 
进行 索引 的 ， 最 好 将 这 种 关系 表示 为 一 个 map， 这 个 map 的 键 是 一 个 枚 举 (起 始 阶段 )， 值 为 
男 一 个 map， 这 第 二 个 map 的 键 为 第 二 个 枚 举 (目标 阶段 )， 它 的 值 为 结果 (阶段 过 渡 )， 即 形 
成 了 Map (起 始 阶段 ，Map (目标 阶段 阶段 过 渡 )) 这 种 形式 。 一 个 阶段 过 渡 所 关联 的 两 个 
阶段 ， 最 好 通过 “数据 与 阶段 过 渡 枚 举 之 间 的 关联 ”来 获取 ， 之 后 用 该 阶段 过 渡 枚 举 来 初始 
化 嵌 套 的 EnumMap 。 

// Using a nested EnumMap to associate data with enum pairs 

public enum Phase { 

SOLID, LIQUID, GAS; 

public enum Transition { 
MELT(SOLID, LIQUID), FREEZE(LIQUID, SOLID), 
BOIL(LIQUID, GAS), CONDENSE(GAS, LIQUID), 
SUBLIME(SOLID, GAS), DEPOSIT(GAS, SOLID); 


private final Phase src; 
private final Phase dst; 


Transition(Phase src, Phase dst) { 


this.src = src; 
this.dst = dst; 


// Initialize the phase transition map 
private static final Map<Phase, Map<Phase,Transition>> m = 
new EnumMap<Phase, Map<Phase,Transition>>(Phase.class); 
Static { 
for (Phase p : Phase.values()) 
m.put(p,new EnumMap<Phase, Transition>(Phase.class)); 
for (Transition trans : Transition. values()) 
m.get(trans.src).put(trans.dst, trans); 


public static Transition from(Phase src, Phase dst) { 
return m.get(src).get(dst); 


} 
} 


初始 化 阶段 过 渡 map 的 代码 看 起 来 可 能 有 点 复杂 ， 但 是 还 不 算 太 糟糕 。map 的 类 型 为 
Map<Phase，Map<Phase，Transition>>， 表 示 是 由 键 为 源 Phase ( 即 第 一 个 phase) 、 值 为 
另 一 个 map 组 成 的 Map ， 其 中 组 成 值 的 Map 是 由 键 值 对 目标 Phase ( 即 第 二 个 Phase) 、 
Transition 组 成 的 。 静 态 初始 化 代码 块 中 的 第 一 个 循环 初始 化 了 外 部 map， 得 到 了 三 个 空 的 
内 容 map。 代 码 块 中 的 第 二 个 循环 利用 每 个 状态 过 渡 常 量 提供 的 起 始 信息 和 目标 信息 初始 
化 了 内 部 map 。 


现在 假设 想 要 给 系统 添加 一 个 新 的 阶段 ; plasma (离子 ) 或 者 电离 气体 。 只 有 两 个 过 渡 
与 这 个 阶段 关联 : 电离 化 ， 它 将 气体 变 成 离子 ， 以 及 消 电离 化 ， 将 离子 变 成 气体 。 为 了 更 新 
基于 数组 的 程序 ， 必 须 给 Phase 添 加 一 种 新 常量 ， 给 Phase.Transition 添 加 两 种 新 常量 ， 用 一 种 
新 的 16 个 元 素 的 版 本 取代 原来 9 个 元 素 的 数组 的 数组 。 如 果 给 数组 添加 的 元 素 过 多 或 者 过 少 ， 
或 者 元 素 放 置 不 妥当 ， 可 就 麻烦 了 : 程序 可 以 编译 ， 但 是 会 在 运行 时 失败 。 为 了 更 新 基于 
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EnumMap 的 版 本 ， 所 要 做 的 就 是 必须 将 PLASMA 添加 到 Phase 列 表 ， 并 将 IONIZE (GAS, 
PLASMA) 和 DEIONIZE (PLASMA，GAS) 添加 到 Phase.Transition 的 列表 中 。 程 序 会 自行 
处 理 所 有 其 他 的 事情 ,你 几乎 没有 机 会 出 错 。 从 内 部 来 看 ，Map 的 Map 被 实现 成 了 数组 的 数组 ， 
因此 在 提升 了 清楚 性 、 安 全 性 和 易 维护 性 的 同时 ， 在 空间 或 者 时 间 上 还 几乎 不 用 任何 开销 。 


总 而 言 之 ， 最 好 不 要 用 序数 来 索引 数组 ， 而 要 使 用 EnumMap。 如 果 你 所 表示 的 这 种 关系 
是 多 维 的 ， 就 使 用 EnumMap<.…，EnumMap<...>>。 应 用 程序 的 程序 员 在 一 般 情 况 下 都 不 使 用 
Enum.ordinal， 即 使 要 用 也 很 少 ， 因 此 这 是 一 种 特殊 情况 ( 见 第 31 条 ) 。 
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就 几乎 所 有 方面 来 看 ， 枚 举 类 型 都 优越 于 本 书 第 一 版 中 所 述 的 类 型 安全 枚 举 模式 
[Bloch01]。 从 表面 上 看 ， 有 一 个 异常 与 可 伸缩 性 有 关 ， 这 个 异常 可 能 处 在 原来 的 模式 中 ， 却 
没有 得 到 语言 构造 的 支持 。 换 句 话说 ， 使 用 这 种 模式 ， 就 有 可 能 让 一 个 枚 举 类 型 去 扩展 男 一 
个 枚 举 类 型 ， 利 用 这 种 语言 特性 ， 则 不 可 能 这 么 做 。 这 绝 非 偶然 。 枚 举 的 可 伸缩 性 最 后 证 明 
基本 上 都 不 是 什么 好 点 子 。 扩 展 类 型 的 元 素 为 基本 类 型 的 实例 ， 基 本 类 型 的 实例 却 不 是 扩展 
类 型 的 元 素 ， 这 样 很 是 混乱 。 目 前 还 没有 很 好 的 方法 来 枚 举 基本 类 型 的 所 有 元 素 及 其 扩展 。 
最 终 ， 可 伸缩 性 会 导致 设计 和 实现 的 许多 方面 变 得 复杂 起 来 。 


也 就 是 说 ， 对 于 可 伸缩 的 枚 举 类 型 而 言 ， 至 少 有 一 种 具有 说 服 力 的 用 例 ， 这 就 是 操作 码 
(operation code), ， 也 称 作 opcode。 操 作 码 是 指 这 样 的 枚 举 类 型 : 它 的 元 素 表 示 在 某 种 机 器 上 
的 那些 操作 ， 例 如 第 30 条 中 的 Operation 类 型 ， 它 表示 一 个 简单 的 计算 器 中 的 某 些 函 数 。 有 时 
候 ， 要 尽 可 能 地 让 API 的 用 户 提供 它们 自己 的 操作 ， 这 样 可 以 有 效 地 扩展 API 所 提供 的 操作 集 。 


幸运 的 是 ， 有 一 种 很 好 的 方法 可 以 利用 枚 举 类 型 来 实现 这 种 效果 。 由 于 枚 举 类 型 可 以 通过 
给 操作 码 类 型 和 (属于 接口 的 标准 实现 的 ) 枚 举 定义 接口 ， 来 实现 任意 接口 ， 基 本 的 想法 就 
是 利用 这 一 事实 。 例 如 ， 以 下 是 第 30 条 中 的 Operation 类 型 的 扩展 版 本 : 


// Emulated extensible enum using an interface 
public interface Operation { 
double apply(double x, double y); 
} 
public enum BasicOperation, implements Operation { 
PLUS("+") { 
public double apply(double x, double y) { return x + y; } 


MINUSC"-") { 
public double apply(double x, double y) { return x - y; } 


3s 
TIMES("«") { 

public double apply(double x, double y) { return x * y; } 
}, 
DIVIDEC"/") { , 

public double apply(double x, double y) { return x / y; } 
33 


private final String symbol; 
BasicOperation(String symbol) { 
this.symbol = symbol; 


} 
@Override public String toString() { 
return symbol; 


an: 
} 


虽然 枚 举 类 型 (BasicOperation) 不 是 可 扩展 的 ， 但 接口 类 型 (Operation) 则 是 可 扩展 的 ， 
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它 是 用 来 表示 API 中 的 操作 的 接口 类 型 。 你 可 以 定义 另 一 个 枚 举 类 型 ， 它 实现 这 个 接口 ， 并 用 
这 个 新 类 型 的 实例 代 赫 基本 类 型 。 例 如 ， 假 设 你 想 要 定义 一 个 上 述 操 作 类 型 的 扩展 ， 由 求知 
(exponentiation) 和 求 余 (remainder) 操作 组 成 。 你 所 要 做 的 就 是 编写 一 个 枚 举 类 型 ， 让 它 
实现 Operation 接 口 : 


// Emulated extension enum 
public enum ExtendedOperation implements Operation { 
EXP("A") { 
public double apply(double x, double y) { 
return Math.pow(x, y); 


}, 
REMAINDER("%") { 
public double apply(double x, double y) { 
return x % y; 


}; 

private final String symbol; 

ExtendedOperation(String symbol) { 
this.symbol = symbol; 


@Override public String toString® { 
return symbol; 
} 


} 


在 可 以 使 用 基础 操作 的 任何 地 方 ， 都 可 以 使 用 新 的 操作 ， 只 要 API 是 被 写成 采用 接口 类 型 
(Operation) 而 非 实 现 (BasicOperation) 。 注 意 ， 在 枚 举 中 ， 不 必 像 在 不 可 扩展 的 枚 举 中 所 做 
的 那样 ， 利 用 特定 于 实例 的 方法 实现 来 声明 抽象 的 apply 方 法 。 这 是 因为 抽象 的 方法 (apply) 
是 接口 Operation) 的 一 部 分 。 


不 仅 可 以 在 任何 需要 “基本 枚 举 ” 的 地 方 单独 传递 一 个 “扩展 枚 举 ” 的 实例 ， 而 且 除 了 那 
些 基本 类 型 的 元 素 之 外 ， 还 可 以 传递 完整 的 扩展 枚 举 类 型 ， 并 使 用 它 的 元 素 。 例 如 ， 通 过 下 
面 这 个 测试 程序 ， 体 验 一 下 上 面 定义 过 的 所 有 扩展 过 的 操作 : 


public static void main(String[] args) { 
double x = Double.parseDouble(args[0]); 
double y = Double.parseDouble(args[1]); 
test(ExtendedOperation.class, x, y); 
} 
private static <T extends Enum<T> & Operation> void test( 
Class<T> opSet, double x, double y) { 
for (Operation op : opSet.getEnumConstants()) 
System.out.printf("%f %s %f = %f%n", 
: X, Op, y, Op.apply(x, y)); 


注意 扩展 过 的 操作 类 型 的 类 的 字面 文字 (ExtendedOperation.class) 从 main 被 传递 给 了 
test 方 法 ， 来 描述 被 扩展 操作 的 集合 。 这 个 类 的 字面 文字 充当 有 限制 的 类 型 令 牌 ( 见 第 29 条 )。 
opSet 参 数 中 公认 很 复杂 的 声明 (<T extends Enum<T> & Operation> Class<T>) 确保 了 Class 
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对 象 既 表 示 枚 举 又 表示 Operation 的 子 类 型 ， 这 正 是 遍历 元 素 和 执行 与 每 个 元 素 相关 联 的 操作 
时 所 需要 的 。 


第 二 种 方法 是 使 用 Collection<? Extends Operation>, -这 是 个 有 限制 的 通配符 类 型 
(bounded wildcard type) ( 见 第 28 条 ) ， 作 为 opSet 人 参数 的 类 型 : 
public static void main(String[] args) { 
double x = Double.parseDouble(args[9]); 


double y = Double.parseDouble(args[1]); 
test (Arrays.asList(ExtendedOperation.values()), x, y); 


private static void test(Collection<? extends Operation> opSet, 
double x, double y) { 
for (Operation op : opSet) 
System.out.printf("%F %s %f = %f%n", 
i X, Op, y, Op.apply(x, y)); 
这 样 得 到 的 代码 没有 那么 复杂 ，test 方 法 也 比较 灵活 一 些 : 它 允许 调用 者 将 多 个 实现 类 型 
的 操作 合并 到 一 起 。 另 一 方面 ， 也 放弃 了 在 指定 操作 上 使 用 EnumSet ( 见 第 32 条 ) 和 
EnumMap ( 见 第 33 条 ) 的 功能 ， 因 此 ， 除 非 需要 灵活 地 合并 多 个 实现 类 型 的 操作 ， 否 则 可 能 


最 好 使 用 有 限制 的 类 型 令 牌 。 
上 面 这 两 段 程序 用 命令 行 参数 2 和 4 运行 时 ， 都 会 产生 这 样 的 输出 : 


4.000000 A 2.000000 = 16.000000 
4.000000 % 2.000000 = 0.000000 


用 接口 模拟 可 伸缩 枚 举 有 个 小 小 的 不 足 ， 即 无 法 将 实现 从 一 个 枚 举 类 型 继承 到 另 一 个 枚 举 
类 型 。 在 上 述 Operation 的 示例 中 ,保存 和 获取 与 某 项 操作 相关 联 的 符号 的 逻辑 代码 ， 可 以 复 
制 到 BasicOperation 和 ExtendedOperation 中 。 在 这 个 例子 中 是 可 以 的 , 因为 复制 的 代码 非常 少 。 
如 果 共 享 功能 比较 多 ， 则 可 以 将 它 封装 在 一 个 辅助 类 或 者 静态 辅助 方法 中 ， 来 避免 代码 的 复 
制 工作 。 


总 而 言 之 ， 虽 然 无 法 编写 可 扩展 的 枚 举 类 型 ， 却 可 以 通过 编写 接口 以 及 实现 该 接口 的 基础 
枚 举 类 型 ， 对 它 进 行 模拟 。 这 样 允 许 客户 端 编写 自己 的 枚 举 来 实现 接口 。 如 果 API 是 根据 接口 
编写 的 ， 那 么 在 可 以 使 用 基础 枚 举 类 型 的 任何 地 方 ， 也 都 可 以 使 用 这 些 枚 举 。 





Java 1.5 发 行 版 本 之 前 ， 一 般 使 用 命名 模式 (naming pattern) 表明 有 些 程序 元 素 需要 通 
过 某 种 工具 或 者 框架 进行 特殊 处 理 。 例 如 ，JUnit 测 试 框架 原本 要 求 它 的 用 户 一 定 要 用 test 作 为 
测试 方法 名 称 的 开头 [Beck04]。 这 种 方法 可 行 ， 但 是 有 几 个 很 严重 的 缺点 。 首 先 ， 文字 拼 写 
错误 会 导致 失败 ， 且 没有 任何 提示 。 例 如 ,假设 不 小 心 将 一 个 测试 方法 命名 为 
tsetSafetyOverride 而 不 是 testSafetyOverride 。JUnit 不 会 出 错 ， 但 也 不 会 执行 测试 ， 造 成 错误 
的 安全 感 〈 即 测试 方法 没有 执行 ， 它 没有 报错 的 可 能 ， 从 而 给 人 以 测试 正确 的 假象 ) 。 


命名 模式 的 第 二 个 缺点 是 ， 无 法 确保 它们 只 用 于 相应 的 程序 元 素 上 。 例 如 ， 假 设 将 某 个 类 
称 作 testSafetyMechanisms, 是 希望 JUnit 会 自动 地 测试 它 所 有 的 方法 , 而 不 管 它们 叫 什 么 名 称 。 
JUnit 还 是 不 会 出 错 ， 但 也 同样 不 会 执行 测试 。 


命名 模式 的 第 三 个 缺点 是 ， 它 们 没有 提供 将 参数 值 与 程序 元 素 关联 起 来 的 好 方法 。 例 如 ， 
假设 想 要 支持 一 种 测试 类 别 ， 它 只 在 抛 出 特殊 异常 时 才 会 成 功 。 异 常 类 型 本 质 上 是 测试 的 一 
个 参数 。 你 可 以 利用 某 种 具体 的 命名 模式 ， 将 异常 类 型 名 称 编码 到 测试 方法 名 称 中 ， 但 是 这 
样 的 代码 会 很 不 雅 观 ， 也 很 脆弱 ( 见 第 50 条 ) 。 编 译 器 不 知道 要 去 检验 准备 命名 异常 的 字符 申 
是 否 真正 命名 成 功 。 如 果 命 名 的 类 不 存在 ， 或 者 不 是 一 个 异常 ， 你 也 要 到 试 着 运行 测试 时 才 
会 发 现 。 


注解 JILS，9.7] 很 好 地 解决 了 所 有 这 些 问 题 。 假 设想 要 定义 一 个 注解 类 型 来 指定 简单 的 测 
试 ， 它 们 自动 运行 ， 并 在 抛 出 异常 时 失败 。 以 下 就 是 这 样 的 一 个 注解 类 型 ， 命 名 为 Test: 


// Marker annotation type declaration 
import java.lang.annotation.x*; 
fae 
+ Indicates that the annotated method is a test method. 
. * Use only on parameterless static methods. 
*/ 
@Retention(RetentionPolicy.RUNTIME) 


@Target(ElementType.M! 
public @interface Test { 
} 


Test 注 解 类 型 的 声明 就 是 它 自身 通过 Retention 和 Target 注 解 进行 了 注解 。 注 解 类 型 声明 中 
的 这 种 注解 被 称 作 元 注解 (meta-annotation ) 。 @Retention(RetentionPolicy.RUNTIME) 元 注 
解 表明 ，Test 注 解 应 该 在 运行 时 保留 。 如 果 没 有 保留 ， 测试 工具 就 无 法 知道 Test 注 解 。 
@Target(ElementType.METHOD) 元 注解 表明 ，Test 注 解 只 在 方法 声明 中 才 是 合法 的 ， 它 不 能 
运用 到 类 声明 、 域 声明 或 者 其 他 程序 元 素 上 。 


注意 Test 注 解 声明 上 方 的 注释 : “Use only on parameterless static method (只 用 于 无 参 的 
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静态 方法 )” 。 如 果 编 译 器 能 够 强制 这 一 限制 最 好 ， 但 是 它 做 不 到 。 编 译 器 可 以 替 你 完成 多 少 
错误 检查 ， 这 是 有 限制 的 ， 即 使 是 利用 注解 。 如 果 将 Test 注 解放 在 实例 方法 的 声明 中 ， 或 者 放 
在 带 有 一 个 或 者 多 个 参数 的 方法 中 ， 测 试 程序 还 是 可 以 编译 ， 让 测试 工具 在 运行 时 来 处 理 这 
个 问题 。 


下 面 就 是 现实 应 用 中 的 Test 注 解 ， 称 作 标记 注解 (marker annotation) ， 因 为 它 没 有 参数 ， 
只 是 “标注 ”被 注解 的 元 素 。 如 果 程 序 员 拼 错 了 Test， 或 者 将 Test 注 解 应 用 到 程序 元 素 而 非 方 
法 声明 ， 程 序 就 无 法 编译 : 


// Program containing marker annotations 
public class Sample { 
@Test public static void m1) { } // Test should pass 
public static void m2() { } 
@Test public static void m3Q) { // Test Should fail 
throw new RuntimeException("Boom") ; 
} 
public static void m4() { } 
@Test public void m5() { } // INVALID USE: nonstatic method 
public static void m6() { } 
@Test public static void m7() { // Test should fail 
throw new RuntimeException("Crash”") ; t 


} 
public static void m8() { } 
} 


Sample 类 有 8 个 静态 方法 ， 其 中 4 个 被 注解 为 测试 。 这 4 个 中 有 2 个 抛 出 了 异常 : m3 和 m7， 
另外 两 个 则 没有 : m1 和 m5。 但 是 其 中 一 个 没有 抛 出 异常 的 被 注解 方法 : m5， 是 一 个 实例 方 
法 ， 因 此 不 属于 注解 的 有 效 使 用 。 总 之 ，Sample 包 含 4 项 测试 : 一 项 会 通过 ， 两 项 会 失败 ， 另 
一 项 无 效 。 没 有 用 Test 注 解 进行 标注 的 4 个 方法 会 被 测试 工具 忽略 。 


Test 注 解 对 Sample 类 的 语义 没有 直接 的 影响 。 它 们 只 负责 提供 信息 供 相 关 的 程序 使 用 。 更 
一 般 地 讲 ， 注 解 永远 不 会 改变 被 注解 代码 的 语义 ,但 是 使 它 可 以 通过 工具 进行 特殊 的 处 理 ， 
例如 像 这 种 简单 的 测试 运行 类 : 


// Program to process marker annotations 
import java.lang.reflect,*; 


public class RunTests { 
public static void main(String[] args) throws Exception { 
int tests = 0; 
int passed = 0; 
Class testClass = Class. forName(args[@]); 
for (Method m : testClass.getDeclaredMethods()) { 
if (m.isAnnotationPresent(Test.class)) { 
tests++; 
try { 
m. invoke(nul1); 
passed++; 
} catch (InvocationTargetException wrappedExc) { 
Throwable exc = wrappedExc.getCause(); 
System.out.printIn(m + " failed: " + exc); 
} catch (Exception exc) { 
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ed 
System.out.println("INVALID @Test: ”+ m); 
} 
} 
System.out.printf("Passed: %d, Failed: %d%n", 
passed, tests - passed); 


} 
} 


测试 运行 工具 在 命令 行 上 使 用 完全 匹配 的 类 名 ， 并 通过 调用 Method.invoke 反 射 式 地 运行 
类 中 所 有 标注 了 Test 的 方法 。isAnnotationPresent 方 法 告知 该 工具 要 运行 哪些 方法 。 如 果 测 试 
方法 抛 出 异常 ， 反 射 机 制 就 会 将 它 封装 在 InvocationTargetException 中 。 该 工具 捕捉 到 了 这 个 
异常 ， 并 打印 失败 报告 ， 包 含 测试 方法 抛 出 的 原始 异常 ， 这 些 信息 是 通过 getCause 方 法 从 
InvocationTargetException 中 提取 出 来 的 。 


如 果 尝 试 通过 反射 调用 测试 方法 时 抛 出 InvocationTargetException 之 外 的 任何 异常 ,表明 
编译 时 没有 捕捉 到 Test 注 解 的 无 效用 法 。 这 种 用 法 包括 实例 方法 的 注解 ， 或 者 带 有 一 个 或 者 多 
个 参数 的 方法 的 注解 ， 或 者 不 可 访问 的 方法 的 注解 。 测 试 运行 类 中 的 第 二 个 catch 块 捕捉 到 了 
这 些 Test 用 法 错误 ， 并 打印 出 相应 的 错误 消息 。 下 面 就 是 RunTests 在 Sample 上 运行 时 打印 的 输 
出 : 


public static void Sample.m3() failed: RuntimeException: Boom 
INVALID @Test: public void Sample.m5() 

public static void Sample.m7() failed: RuntimeException: Crash 
Passed: 1, Failed: 3 


现在 我 们 要 针对 只 在 抛 出 特殊 异常 时 才 成 功 的 测试 添加 支持 。 为 此 我 们 需要 一 个 新 的 注解 
类 型 ; 


// Annotation type with a parameter 
import java. lang.annotation.«; 
[xe 
* Indicates that the annotated method is a test method that 
* must throw the designated exception to succeed. 
*/ 
@Retention(RetentionPolicy.RUNTIME) 
@Target(ElementType .METHOD) 
public @interface ExceptionTest { 
Class<? extends Exception> value(); 


这 个 注解 的 参数 类 型 是 Class<? extends Exception>。 这 个 通配符 类 型 无 疑 很 绕 口 。 它 在 
英语 中 的 意思 是 : 某 个 扩展 Exception 的 类 的 Class 对 象 ， 它 允 许 注解 的 用 户 指定 任何 异常 类 型 。 
这 种 用 法 是 有 限制 的 类 型 令 牌 ( 见 第 29 条 ) 的 一 个 示例 。 下 面 就 是 实际 应 用 中 的 这 个 注解 。 
注意 类 名 称 被 用 作 了 注解 的 参数 值 ; 

// Program containing annotations with a parameter 


public class Sample2 { 
@ExceptionTest (ArithmeticException.class) 


150 FO 





public static void m1() { // Test should pass 
int i = 0; 
i=-i/i; 


} . 
@ExceptionTest (ArithmeticException.class) 
public static void m2() { // Should fail (wrong exception) 
int[] a = new int[0]; 
int i = afl); 


} 

@ExceptionTest (ArithmeticException.class) 

public static void m3() { } // Should fail (no exception) 
} 


现在 我 们 要 修改 一 下 测试 运行 工具 来 处 理 新 的 注解 。 这 其 中 包括 将 以 下 代码 添加 到 main 
方法 中 : 


if (m.isAnnotationPresent(ExceptionTest.class)) { 
tests++; 
try { 
m. invoke(nul1); 
System.out.printf("Test %s failed: no exception%n", m); 
} catch (InvocationTargetException wrappedEx) { 
Throwable exc = wrappedEx.getCause() ; 
Class<?-extends Exception> excType = 
m.getAnnotat ion(ExceptionTest.class).value(); 
if (excType.isInstance(exc)) { 
passed++; 
} else { 
System.out.printf( 
"Test %s failed: expected %s, got %s%n", 
m, excType.getName(), exc); 


} catch (Exception exc) { 
System.out.printinC"INVALID @Test: ”+ m); 


} 


这 段 代码 类 似 于 用 来 处 理 Test 注 解 的 代码 , 但 有 一 处 不 同 : 这 段 代 码 提取 了 注解 参数 的 值 ， 
并 用 它 检 验 该 测试 抛 出 的 异常 是 否 为 正确 的 类 型 。 没 有 显 式 的 转换 ， 因 此 没有 出 现 
ClassCastException 的 危险 。 编 译 过 的 测试 程序 确保 它 的 注解 参数 表示 的 是 有 效 的 异常 类 型 ， 
需要 提醒 一 点 : 有 可 能 注解 参数 在 编译 时 是 有 效 的 ， 但 是 表示 特定 异常 类 型 的 类 文件 在 运行 
时 却 不 再 存在 。 在 这 种 希望 很 少 出 现 的 情况 下 ， 测 试 运行 类 会 抛 出 TypeNotPresentException 
异常 。 


将 上 面 的 异常 测试 示例 再 深入 一 点 ， 想 像 测 试 可 以 在 抛 出 任何 一 种 指定 异常 时 都 得 到 通 
过 。 注 解 机 制 有 一 种 工具 ， 使 得 支持 这 种 用 法 变 得 十 分 容易 。 假 设 我 们 将 ExceptionTest 注 解 
的 参数 类 型 改 成 Class 对 象 的 一 个 数组 : 


// Annotation type with an array parameter 
@Retention(RetentionPolicy.RUNTIME) 
@Target(ElementType.METHOD) 
public @interface ExceptionTest { 

Class<? extends Exception>[] value(); 


} 
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注解 中 数组 参数 的 语法 十 分 灵活 。 它 是 进行 过 优化 的 单元 素数 组 。 使 用 了 ExceptionTest 
新 版 的 数组 参数 之 后 ， 之 前 的 所 有 ExceptionTest 注 解 仍然 有 效 ， 并 产生 单元 素 的 数组 。 为 了 
指定 多 元 素 的 数组 ， 要 用 花 括 号 〈{}) 将 元 素 包围 起 来 ， 并 用 逗号 (,) 将 它们 隔 开 : 


// Code containing an annotation with an array parameter 
@ExceptionTest({ IndexOutOfBoundsException.class, 
NullPointerException.class }) 
public static void doublyBad() { 
List<String> list = new ArrayList<String>(); 


// The spec permits this method to throw either 
// IndexOutOfBoundsException or Nul1lPointerException 
list.addA11(5, null); 

} 


修改 测试 运行 工具 来 处 理 新 的 ExceptionTest 相 当 简 单 。 下 面 的 代码 代替 了 原来 的 代码 : 


if (m.isAnnotationPresent(ExceptionTest.class)) { 
tests++; 
try { 
m. invoke(null); 
System.out.printf("Test %s failed: no exceptioniin”, m); 
} catch (Throwable wrappedExc) { 
Throwable exc = wrappedExc.getCause(); 
Class<? extends Exception>[] excTypes = 
m.getAnnotation(ExceptionTest.class).value(); 
int oldPassed = passed; 
for (Class<? extends Exception> excType : excTypes) { 
if CexcType.isInstance(exc)) { 
passed++; 
break; 
} 
} 
if (passed == 01dPassed) 
System.out.printf("Test %s failed: %s %n", m, exc); 


} 
} 


本 条 目 中 开发 的 测试 框架 只 是 一 个 试验 ， 但 它 清 楚 地 示范 了 注解 之 于 命名 模式 的 优越 性 。 
它 这 还 只 是 揭 开 了 注解 功能 的 冰山 一 角 。 如 果 是 在 编写 一 个 需要 程序 员 给 源 文件 添加 信息 的 
工具 ， 就 要 定义 一 组 适当 的 注解 类 型 。 了 既然 有 了 注解 ， 就 完全 没有 理由 再 使 用 命名 模式 了 。 


也 就 是 说 ,除了 “工具 铁匠 (toolsmiths 一 一 特定 的 程序 员 )” 之 外 ， 大 多 数 程 序 员 都 不 必 
定义 注解 类 型 。 但 是 所 有 的 程序 员 都 应 该 使 用 Java 平 台所 提供 的 预定 义 的 注解 类 型 ( 见 第 36 
和 24 条 )。 还 要 考虑 使 用 IDE 或 者 静态 分 析 工 具 所 提供 的 任何 注解 。 这 种 注解 可 以 提升 由 这 些 
工具 所 提供 的 诊断 信息 的 质量 。 但 是 要 注意 这 些 注解 还 没有 标准 化 ， 因 此 如 果 变 换 工具 或 者 
形成 标准 ， 就 有 很 多 工作 要 做 了 。 
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随 着 Java 1.5 发 行 版 本 中 增加 注解 ， 类 库 中 也 增加 了 几 种 注解 类 型 JILS，9.6]。 对 于 传统 
的 程序 员 而 言 ， 这 里 面 最 重要 的 就 是 Override 注 解 了 。 这 个 注解 只 能 用 在 方法 声明 中 ， 它 表示 
被 注解 的 方法 声明 覆盖 了 超 类 型 中 的 一 个 声明 。 如 果 坚 持 使 用 这 个 注解 ， 可 以 防止 一 大 类 的 
非法 错误 。 考 虑 下 面 的 程序 ， 这 里 的 类 Bigram 表 示 一 个 双 字 母 组 或 者 有 序 的 字母 对 : 


// Can you spot the bug? 
public class Bigram { 
private final char first; 
private final char second; 
public Bigram(char first, char second) { 
this.first = first; 
this.second = second; 


} 
public boolean equals(Bigram b) { 
return b.first == first && b.second == second; 


} 
public int hashCode() { 
return 31 * first + second; 


public static void main(String[] args) { 
Set<Bigram> s = new HashSet<Bigram>(); 
for (Cint i = 0; i < 10; i++) 
for (char ch = ‘a'; ch <= 'z'; ch++) 
s.add(new Bigram(ch, ch)); 
System.out.printin(s.size()); 


} 


主 程序 反复 地 将 26 个 双 字母 组 添加 到 集合 中 ， 每 个 双 字 母 组 都 由 两 个 相同 的 小 写字 母 组 
成 。 随 后 它 打印 出 集合 的 大 小 。 你 可 能 以 为 程序 打印 出 的 大 小 为 26， 因 为 集合 不 能 包含 重复 。 
如 果 你 试 着 运行 程序 ， 会 发 现 它 打印 的 不 是 26 而 是 260。 哪 里 出 错 了 呢 ? 


很 显然 ，Bigram 类 的 创建 者 原本 想 要 覆盖 equals 方 法 ( 见 第 8 条 )， 同 时 还 记得 覆盖 了 
hashCode。 遗 憾 的 是 ， 不 幸 的 程序 员 没 能 覆盖 equals， 而 是 将 它 重 载 了 -( 见 第 41 条 )。 为 了 覆 
盖 Object.equals ， 必 须 定 义 一 个 参数 为 Object 类 型 的 equals 方 法 ， 但 是 Bigram 的 equals 方 法 的 
参数 并 不 是 Object 类 型 ， 因 此 Bigram 从 Object 继承 了 equals 方 法 。 这 个 equals 方 法 测试 对 象 的 
同一 性 ， 就 像 == 操 作 符 一 样 。 每 个 bigram 的 10 个 备份 中 ， 每 一 个 都 与 其 余 的 9 个 不 同 ， 因此 
Object.equals 认 为 它们 不 相等 ， 这 正解 释 了 程序 为 什么 会 打印 出 260 的 原因 。 


幸运 的 是 ， 编 译 器 可 以 帮助 你 发 现 这 个 错误 ， 但 是 只 有 当 你 告知 编译 器 你 想 要 覆盖 
Object.equals 时 才 行 。 为 了 做 到 这 一 点 ， 要 用 @Override 标 注 Bigram.euqals ， 如 下 所 示 : 
@Override public boolean equals(Bigram b) { 


return b.first == first && b.second == second; 


} 
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如 果 播 入 这 个 注解 ， 并 试 着 重新 编译 程序 ， 编 译 器 就 会 产生 一 条 像 这 样 的 错误 消息 : 


Bigram.java:10: method does not override or implement a method 
from a Supertype 

@Override public boolean equals(Bigram b) { 

A 


你 会 立即 意识 到 哪里 错 了 ， 拍 拍 自 己 的 头 ， 忱 然 大 悟 ， 马 上 用 正确 的 来 取代 出 错 的 equals 
实现 ( 见 第 8 条 ): 
@Override public boolean equals(Object o) { 
if (!(o instanceof Bigram)) 
return false; 
Bigram b = (Bigram) o; 
return b.first == first && b.second == second; 
} 
因此 ， 应 该 在 你 想 要 覆盖 超 类 声明 的 每 个 方法 声明 中 使 用 Override 注 解 。 这 一 规则 有 个 
小 小 的 例外 。 如 果 你 在 编写 一 个 没有 标注 为 抽象 的 类 ， 并 且 确 信 它 覆盖 了 抽象 的 方法 ， 在 这 
种 情况 下 ， 就 不 必 将 Override 注 解放 在 该 方法 上 了 。 在 没有 声明 为 抽象 的 类 中 ， 如 果 没 有 和 覆盖 
抽象 的 超 类 方法 ， 编 译 器 就 会 发 出 一 条 错误 消息 。 但 是 ， 你 可 能 希望 关注 类 中 所 有 覆盖 超 类 


方法 的 方法 ， 在 这 种 情况 下 ， 也 可 以 放心 地 标注 这 些 方法 。 


现代 的 IDE 提 供 了 坚持 使 用 Override 注 解 的 另 一 种 理由 。 这 种 IDE 具 有 自动 检查 功能 ， 称 
作 代 码 检 验 (code inspection) 。 如 果 启 用 相应 的 代码 检验 功能 ， 当 有 一 个 方法 没有 Override 
注解 ， 却 覆盖 了 超 类 方法 时 ，IDE 就 会 产生 一 条 敬告。 如 果 坚 持 使 用 Override 注 解 ， 这 些 警 告 
就 会 提醒 你 警惕 无 意识 的 覆盖 。 这 些 警告 补充 了 编译 器 的 错误 消息 ， 提 醒 你 警惕 无 意识 的 覆 
盖 失 败 。IDE 和 编译 器 ， 可 以 确保 你 覆盖 任何 你 想 要 覆盖 的 方法 ， 无 一 遗漏 。 


如 果 你 使 用 的 是 Java 1.6 或 者 更 新 的 发 行 版 本 ，Override 注 解 在 查找 Bug 方 面 还 提供 了 更 多 
的 帮助 。 在 Java 1.6 发 行 版 本 中 ， 在 覆盖 接口 以 及 类 的 方法 声明 中 使 用 Override 注 解 变 成 是 合 
法 的 了 。 在 被 声明 为 去 实现 某 接口 的 具体 类 中 ,不必 标注 出 你 想 要 这 些 方法 来 覆盖 接口 方法 ， 
因为 如 果 你 的 类 没有 实现 每 一 个 接口 方法 ， 编 译 器 就 会 产生 一 条 错误 消息 。 当 然 ， 你 可 以 选 
择 只 包括 这 些 注解 ， 来 标明 它们 是 接口 方法 ,但 是 这 并 非 绝 对 必要 。 


但 是 在 抽象 类 或 者 接口 中 , 还 是 值得 标注 所 有 你 想 要 的 方法 , 来 覆盖 超 类 或 者 超 接口 方法 ， 
无 论 是 具体 的 还 是 抽象 的 。 例 如 ，Set 接 口 没 有 给 Collection 接 口 添加 新 方法 ， 因 此 它 应 该 在 它 
的 所 有 方法 声明 中 包括 Override 注 解 ， 以 确保 它 不 会 意外 地 给 Collection 接 口 添加 任何 新 方法 。 


总 而 言 之 ， 如 果 在 你 想 要 的 每 个 方法 声明 中 使 用 Override 注 解 来 覆盖 超 类 声明 ， 编 译 器 就 
可 以 替 你 防止 大 量 的 错误 ， 但 有 一 个 例外 。 在 具体 的 类 中 ， 不 必 标注 你 确信 覆盖 了 抽象 方法 
声明 的 方法 (虽然 这 么 做 也 没有 什么 坏处 )。 





标记 接口 (marker interface) 是 没有 包含 方法 声明 的 接口 ， 而 只 是 指明 (或 者 “标明 ”) 
一 个 类 实现 了 具有 某 种 属性 的 接口 。 例 如 ， 考 虑 Serializable 接 口 ( 见 第 11 章 )。 通 过 实现 这 个 
接口 ， 类 表明 它 的 实例 可 以 被 写 到 ObjectOutputStream (或 者 “被 序列 化 ”)。 


你 可 能 听 说 过 标记 注解 ( 见 第 35 条 ) 使 得 标记 接口 过 时 了 。 这 种 断言 是 不 正确 的 。 标 记 
接口 有 两 点 胜 过 标记 注解 。 首 先 ， 也 是 最 重要 的 一 点 是 ， 标 记 接 口 定 义 的 类 型 是 由 被 标记 类 
的 实例 实现 的 ; 标记 注解 则 没有 定义 这 样 的 类 型 。 这 个 类 型 允许 你 在 编译 时 捕捉 在 使 用 标记 
注解 的 情况 下 要 到 运行 时 才能 捕捉 到 的 错误 。 ` 


就 Serializable 标 记 接 口 而 言 ， 如 果 它 的 参数 设 有 实现 该 接口 ，ObjectOutputStream.write 
(Object) 方 法 将 会 失败 。 令 人 不 解 的 是 ，ObjectOutputStream API 的 创建 者 在 声明 write 方法 时 
并 没有 利用 Serializable 接 口 。 该 方法 的 参数 类 型 应 该 为 Serializable 而 非 Object。 因 此 ， 试 着 
在 没有 实现 Serializable 的 对 象 上 调用 ObjectOutputStream.write， 只 会 在 运行 时 失败 ， 但 也 并 
不 一 定 如 此 。 


标记 接口 胜 过 标记 注解 的 另 一 个 优点 是 ， 它 们 可 以 被 更 加 精确 地 进行 锁定 。 如 果 注 解 类 型 
利用 @Target (ElementType.TYPE) 声明 ， 它 就 可 以 被 应 用 到 任何 类 或 者 接口 。 假 设 有 一 个 
标记 只 适用 于 特殊 接口 的 实现 。 如 果 将 它 定义 成 一 个 标记 接口 ， 就 可 以 用 它 将 唯一 的 接口 扩 
展 成 它 适用 的 接口 。 


Set 接 口 可 以 说 就 是 这 种 有 限制 的 标记 接口 (restricted marker interface) 。 它 只 适用 于 
Collection 子 类 型 ， 但 是 它 不 会 添加 除了 Collection 定 义 之 外 的 方法 。 一 般 情 况 下 ， 不 把 它 当 作 
是 标记 接口 ， 因 为 它 改进 了 几 个 Collection 方 法 的 契约 ， 包 括 add、equals 和 hashCode。 但 是 很 
容易 想像 只 适用 于 某 种 特殊 接口 的 子 类 型 的 标记 接口 ， 它 没有 改进 接 日 的 任何 方法 的 契约 。 
这 种 标记 接口 可 以 描述 整个 对 象 的 某 个 约束 条 件 ， 或 者 表明 实例 能 够 利用 其 他 某 个 类 的 方法 
进行 处 理 (就 像 Serializable 接 口 表 明 实 例 可 以 通过 ObjectOutputStream 进 行 处 理 一 样 ) 。 


标记 注解 胜 过 标记 接口 的 最 大 优点 在 于 ， 它 可 以 通过 默认 的 方式 添加 一 个 或 者 多 个 注解 类 
型 元 素 ， 给 已 被 使 用 的 注解 类 型 添加 更 多 的 信息 LILS，9:6]。 随 着 时 间 的 推移 ， 简 单 的 标记 注 
解 类 型 可 以 演变 成 更 加 丰富 的 注解 类 型 。 这 种 演变 对 于 标记 接口 而 言 则 是 不 可 能 的 ， 因 为 它 
通常 不 可 能 在 实现 接口 之 后 再 给 它 添加 方法 ( 见 第 18 条 )。 


标记 注解 的 另 一 个 优点 在 于 ， 它 们 是 更 大 的 注解 机 制 的 一 部 分 。 因 此 ， 标 记 注 解 在 那些 支 
持 注解 作为 编程 元 素 之 一 的 框架 中 同样 具有 一 致 性 。 
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那么 什么 时 候 应 该 使 用 标记 注解 ， 什 么 时 候 应 该 使 用 标记 接口 呢 ? 很 显然 ， 如 果 标 记 是 应 
用 到 任何 程序 元 素 而 不 是 类 或 者 接口 ， 就 必须 使 用 注解 ， 因 为 只 有 类 和 接口 可 以 用 来 实现 或 
者 扩展 接口 。 如 果 标 记 只 应 用 给 类 和 接口 ， 就 要 问 问 自己 : 我 要 编写 一 个 还 是 多 个 只 接受 有 
这 种 标记 的 方法 呢 ? 如 果 是 这 种 情况 ， 就 应 该 优先 使 用 标记 接口 而 非 注解 。 这 样 你 就 可 以 用 
接口 作为 相关 方法 的 参数 类 型 ， 它 真正 可 以 为 你 提供 编译 时 进行 类 型 检查 的 好 处 。 


如 果 你 对 第 一 个 问题 的 回答 是 否定 的 ， 就 要 再 问 问 自己 : 我 要 永远 限制 这 个 标记 只 用 于 特 
殊 接 口 的 元 素 吗 ? 如 果 是 ， 最 好 将 标记 定义 成 该 接口 的 一 个 子 接口 。 如 果 这 两 个 问题 的 答案 
都 是 否定 的 ， 或 许 就 应 该 使 用 标记 注解 。 


总 而 言 之 ， 标 记 接 口 和 标记 注解 都 各 有 用 处 。 如 果 想 要 定义 一 个 任何 新 方法 都 不 会 与 之 关 
联 的 类 型 ， 标 记 接 口 就 是 最 好 的 选择 。 如 果 想 要 标记 程序 元 素 而 非 类 和 接口 ， 考 虑 到 未 来 可 
能 要 给 标记 添加 更 多 的 信息 ， 或 者 标记 要 适合 于 已 经 广泛 使 用 了 注解 类 型 的 框架 ， 那 么 标记 
注解 就 是 正确 的 选择 。 如 果 你 发 现 自己 在 编写 的 是 目标 为 ElementType.TYPE 的 标记 注解 类 
型 ， 就 要 花 点 时 间 考 虑 清楚 ， 它 是 否 真 的 应 该 为 注解 类 型 ， 想 想 标 记 接 口 是 否 会 更 加 合适 呢 。 


从 某 种 意义 上 说 ， 本 条 目 与 第 19 条 中 “如 果 不 想 定义 类 型 就 不 要 使 用 接口 ”的 说 法 相反 。 
本 条 目 最 接近 的 意思 是 说 : 如 果 想 要 定义 类 型 ， 一 定 要 使 用 接口 。 
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本 童 要 讨论 方法 设计 的 几 个 方面 ， 如 何 处 理 参数 和 返回 值 ， 如 何 设计 方法 签名 ， 如 何 为 
方法 编写 文档 。 本 章 中 大 多 数 内 容 既 适用 于 构造 器 ， 也 适用 于 普通 的 方法 。 与 第 5 章 一 样 ， 本 
章 的 焦点 也 集中 在 可 用 性 、 健 壮 性 和 灵活 性 上 。 





绝 大 多 数 方法 和 构造 器 对 于 传递 给 它们 的 参数 值 都 会 有 某 些 限制 。 例 如 ， 索 引 值 必须 是 非 
负数 ， 对 象 引 用 不 能 为 null， 等 等 ， 这 些 都 是 很 常见 的 。 你 应 该 在 文档 中 清楚 地 指明 所 有 这 些 
限制 ， 并 且 在 方法 体 的 开头 处 检查 参数 ， 以 强制 施加 这 些 限 制 。 这 是 “应 该 在 发 生 错误 之 后 
尽快 检测 出 错误 ”这 一 普遍 原则 的 一 个 具体 情形 。 如 果 不 能 做 到 这 一 点 ， 检 测 到 错误 的 可 能 
性 就 比较 小 ， 即 使 检测 到 错误 了 ， 也 比较 难以 确定 错误 的 根源 。 


如 有 果 传 递 无 效 的 参数 值 给 方法 ， 这 个 方法 在 执行 之 前 先 对 参数 进行 了 检查 ， 那 么 它 很 快 就 
会 失败 ， 并 且 清 楚 地 出 现 适 当 的 异常 (exception) 。 如 果 这 个 方法 没有 检查 它 的 参数 ， 就 有 可 
能 发 生 几 种 情形 。 该 方法 可 能 在 处 理 过 程 中 失败 ， 并 且 产生 令 人 费解 的 异常 。 更 糟糕 的 是 ， 
该 方法 可 以 正常 返回 ， 但 是 会 悄悄 地 计算 出 错误 的 结果 。 最 糟糕 的 是 ， 该 方法 可 以 正常 返回 ， 
但 是 却 使 得 某 个 对 象 处 于 被 破坏 的 状态 ， 将 来 在 某 个 不 确定 的 时 候 ， 在 某 个 不 相关 的 点 上 会 
引发 错误 。 


对 于 公有 的 方法 ， 要 用 Javadoc 的 @throws 标 签 (tag) 在 文档 中 说 明 违 反 参 数值 限制 时 会 抛 出 
的 异常 ( 见 第 62 条 )。 这 样 的 异常 通常 为 IllegalArgumentException、 IndexOutOfBoundsException 
或 NullPointerException ( 见 第 60 条 ) 。 一 旦 在 文档 中 记录 了 对 于 方法 参数 的 限制 ， 并 且 记录 了 
一 旦 违反 这 些 限制 将 要 抛 出 的 异常 ， 强 加 这 些 限制 就 是 非常 简单 的 事情 了 。 下 面 是 一 个 典型 
的 例子 : 
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[ux 
+ Returns a BigInteger whose value is (this mod m). This method 
+ differs from the remainder method in that it always returns a 
* non-negative BigInteger. 
* 
+ @param m the modulus, which must be positive 
* @return this mod m 
+ @throws ArithmeticException if m is less than or equal to 0 
* 
/ 
public BigInteger mod(BigInteger m) { 
if (m.signum() <= 0) 
throw new ArithmeticException("Modulus <= @: " + m); 
... // Do the computation 
} 


对 于 未 被 导出 的 方法 (unexported method) ， 作 为 包 的 创建 者 ， 你 可 以 控制 这 个 方法 将 在 
哪些 情况 下 被 调用 ， 因 此 你 可 以 ， 也 应 该 确保 只 将 有 效 的 参数 值 传递 进来 。 因 此 ， 非 公有 的 
方法 通常 应 该 使 用 断言 (assertion) 来 检查 它们 的 参数 ， 具 体 做 法 如 下 所 示 : 


// Private helper function for a recursive sort 
private static void sort(long a[], int offset, int length) { 
assert a != null; 
assert offset >= 0 && offset <= a.length; 
assert length >= 0 && length <= a.length - offset; 
j ... // Do the computation 
从 本 质 上 讲 ， 这 些 断 言 是 在 声称 被 断言 的 条 件 将 会 为 真 ， 无 论 外 围 包 的 客户 端 如 何 使 用 它 。 
不 同 于 一 般 的 有 效 性 检查 ， 断 言 如 果 失 败 ， 将 会 抛 出 AssertionError。 也 不 同 于 一 般 的 有 效 性 检 
查 ， 如 果 它 们 没有 起 到 作用 ， 本 质 上 也 不 会 有 成 本 开销 ， 除 非 通 过 将 -ea (或 者 -enableassertions) 


标记 (flag) 传递 给 Java 解 释 器 ， 来 启用 它们 。 关 于 断言 的 更 多 信息 ， 请 见 Sun 的 教程 [Asserts]。 


对 于 有 些 参 数 ， 方 法 本 身 没有 用 到 ， 却 被 保存 起 来 供 以 后 使 用 ， 检 验 这 类 参数 的 有 效 性 尤 
为 重要 。 例 如 ， 考 虑 第 83 页 中 的 静态 工厂 方法 ， 它 的 参数 为 一 个 int 数 组 , :并 返回 该 数组 的 List 
视图 。 如 果 这 个 方法 的 客户 端 要 传递 null， 该 方法 将 会 抛 出 一 个 NullPointerException ， 因 为 该 
方法 包含 一 个 显 式 的 条 件 检查 。 如 果 省 略 了 这 个 条 件 检查 ， 它 就 会 返回 一 个 指向 新 建 List 实 例 
的 引用 ， 一 旦 客户 端 企图 使 用 这 个 引用 ， 立 即 就 会 抛 出 NullPointerException。 到 那 时 ， 要 想 找 
到 List 实 例 的 来 源 可 能 就 非常 困难 了 ， 从 而 使 得 调试 工作 极 大 地 复杂 化 了 。 


如 前 所 述 ， 有 些 参数 被 方法 保存 起 来 供 以 后 使 用 ， 构 造 器 正 是 代表 了 这 种 原则 的 一 种 特殊 
情形 。 检 查 构 造 器 参数 的 有 效 性 是 非常 重要 的 ， 这 样 可 以 避免 构造 出 来 的 对 象 违 反 了 这 个 类 
的 约束 条 件 。 


在 方法 执行 它 的 计算 任务 之 前 ， 应 该 先 检 查 它 的 参数 ， 这 一 规则 也 有 例外 。 一 个 很 重要 的 
例外 是 ， 在 有 些 情 况 下 ， 有 效 性 检查 工作 非常 昂贵 ， 或 者 根本 是 不 切实 际 的 ， 而 且 有 效 性 检 
查 已 隐 含 在 计算 过 程 中 完成 。 例 如 ， 考 虑 一 个 为 对 象 列表 排序 的 方法 : Collections.sort (List), 
列表 中 的 所 有 对 象 都 必须 是 可 以 相互 比较 的 。 在 为 列表 排序 的 过 程 中 ， 列 表 中 的 每 个 对 象 将 
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与 其 他 某 个 对 象 进行 比较 。 如 果 这 些 对 象 不 能 相互 比较 ， 其 中 的 某 个 比较 操作 就 会 抛 出 
ClassCastException， 这 正 是 sort 方 法 所 应 该 做 的 事情 。 因 此 ， 提 前 检查 列表 中 的 元 素 是 否 可 
以 相互 比较 ， 这 并 没有 多 大 意义 。 然 而 ， 请 注意 ， 和 
败 原 子 性 (failure atomicity) ( 见 第 64 条 ) 。 


有 了 时候， 某 些 计算 会 隐 式 地 执行 必要 的 有 效 性 检查 ， 但 是 如 果 检 查 不 成 功 ， 就 会 抛 出 错误 
的 异常 。 换 句 话说 ， 由 于 无 效 的 参数 值 而 导致 计算 过 程 抛 出 的 异常 ， 与 文档 中 标明 这 个 方法 
将 抛 出 的 异常 并 不 相符 。 在 这 种 情况 下 ， 应 该 使 用 第 61 条 中 讲述 的 异常 转译 (exception 
translation) 技术 ， 将 计算 过 程 中 抛 出 的 异常 转换 为 正确 的 异常 。 


不 要 从 本 条 目的 内 容 中 得 出 这 样 的 结论 : 对 参数 的 任何 限制 都 是 件 好事 。 相 反 ， 在 设计 方 
法 时 ， 应 该 使 它们 尽 可 能 地 通用 ， 并 符合 实际 的 需要 。 假 如 方法 对 于 它 能 接受 的 所 有 参数 值 
都 能 够 完成 合理 的 工作 ， 对 参数 的 限制 就 应 该 是 越 少 越 好 。 然 而 ， 通 常情 况 下 ， 有 些 限制 对 
于 被 实现 的 抽象 来 说 是 固有 的 。 


简 而 言 之 ， 每 当 编 写 方法 或 者 构造 器 的 时 候 ， 应 该 考虑 它 的 参数 有 哪些 限制 。 应 该 把 这 些 
限制 写 到 文档 中 ， 并 且 在 这 个 方法 体 的 开头 处 ， 通 过 显 式 的 检查 来 实施 这 些 限 制 。 养 成 这 样 
的 习惯 是 非常 重要 的 。 只 要 有 效 性 检查 有 一 次 失败 ， 你 为 必要 的 有 效 性 检查 所 付出 的 努力 便 
都 可 以 连 本 带 利 地 得 到 偿还 了 。 





使 Java 使 用 起 来 如 此 舒适 的 一 个 因素 在 于 ， 它 是 一 门 安全 的 语言 (safe language) 。 这 意 
味 着 ， 它 对 于 缓冲 区 溢出 、 数 组 越界 、 非 法 指针 以 及 其 他 的 内 存 破坏 错误 都 自动 免疫 ， 而 这 
些 错 误 却 困扰 着 诸如 C 和 C++ 这 样 的 不 安全 语言 。 在 一 门 安 全 语言 中 ， 在 设计 类 的 时 候 ， 可 以 
确切 地 知道 ， 无 论 系统 的 其 他 部 分 发 生 什么 事情 ， 这 些 类 的 约束 都 可 以 保持 为 真 。 对 于 那些 
“把 所 有 内 存 当 作 一 个 巨大 的 数组 来 看 待 ”的 语言 来 说 ， 这 是 不 可 能 的 。 


即使 在 安全 的 语言 中 ， 如 果 不 采取 一 点 措施 ， 还 是 无 法 与 其 他 的 类 隔离 开 来 。 假 设 类 的 客 
户 端 会 尽 其 所 能 来 破坏 这 个 类 的 约束 条 件 ， 因 此 你 必须 保护 性 地 设计 程序 。 实 际 上 ， 只 有 当 
有 人 试图 破坏 系统 的 安全 性 时 ， 才 可 能 发 生 这 种 情形 ， 更 有 可 能 的 是 ， 对 你 的 API 产 生 误解 的 
程序 员 ， 所 导致 的 各 种 不 可 预期 的 行为 ， 只 好 由 类 来 处 理 。 无 论 是 哪 种 情况 ， 编 写 一 些 面 对 
客户 的 不 良 行为 时 仍 能 保持 健壮 性 的 类 ， 这 是 非常 值得 投入 时 间 去 做 的 事情 。 


没有 对 象 的 帮助 时 ， 虽 然 另 一 个 类 不 可 能 修改 对 象 的 内 部 状态 ， 但 是 对 象 很 容易 在 无 意识 
的 情况 下 提供 这 种 帮助 。 例 如 ， 考 虑 下 面 的 类 ， 它 声称 可 以 表示 一 段 不 可 变 的 时 间 周 期 : 


// Broken “immutable” time period class 
public final class Period { 

private final Date start; 

private final Date end; 


[ae 

* @param start the beginning of the period 

+ @param end the end of the period; must not precede start 
+ @throws IllegalArgumentException if start is after end 

+ @throws NullPointerException if start or end is null 


*/ 
public Period(Date start, Date end) { 
if (start.compareTo(end) > 0) 
throw new IllegalArgumentException( 
start + " after " + end); 
this.start = start; 
this.end = end; 
} 


public Date start() { 
return start; 


public Date end() { 
return end; 
} 
. // Remainder omitted 


乍 一 看 ， 这 个 类 似乎 是 不 可 变 的 ， 并且 强加 了 约束 条 件 : 周期 的 起 始 时 间 (start) 不 能 
在 结束 时 间 (end) 之 后 。 然 而 ， 因 为 Date 类 本 身 是 可 变 的 ,因此 很 容易 违反 这 个 约束 条 件 : 
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// Attack the internals of a Period instance 
Date start = new Date(); 

Date end = new Date(); 

Period p = new Period(start, end); 
end.setYear(78); // Modifies internals of p! 


为 了 保护 Period 实 例 的 内 部 信息 避免 受到 这 种 攻击 ， 对 于 构造 器 的 每 个 可 变 参 数 进行 保护 
性 拷贝 (defensive copy) 是 必要 的 ， 并 且 使 用 备份 对 象 作 为 Period 实 例 的 组 件 ， 而 不 使 用 原 
始 的 对 象 : 
// Repaired constructor - makes defensive copies of parameters 
public Period(Date start, Date end) { 
this.start = new Date(start.getTime()); 


this.end = new Date(end.getTime()); 


if (this.start.compareTo(this.end) > @) 
throw new I]legalArgumentException(start +" after "+ end); 
} 


用 了 新 的 构造 器 之 后 ， 上 述 的 攻击 对 于 Period 实 例 不 再 有 效 。 注 意 ， 保护 性 找 贝 是 在 检查 
参数 的 有 效 性 ( 见 第 38 条 ) 之 前 进行 的 ， 并 且 有 效 性 检查 是 针对 找 贝 之 后 的 对 象 ， 而 不 是 针 
对 原始 的 对 象 。 虽 然 这 样 做 看 起 来 有 点 不 太 自 然 ， 却 是 必要 的 。 这 样 做 可 以 避免 在 “危险 阶 
Be (window of vulnerability) ”期 间 从 另 一 个 线程 改变 类 的 参数 ， 这 里 的 危险 阶段 是 指 从 检查 
参数 开始 ， 直 到 拷贝 参数 之 间 的 时 间 段 。( 在 计算 机 安全 社区 中 ， 这 被 称 作 Time-Of- 
Check/Time-Of-Use 或 者 TOCTOU 攻 击 [Viega01]。 ) 


同时 也 请 注意 ， 我 们 没有 用 Date 的 clone 方 法 来 进行 保护 性 拷贝 。 因 为 Date 是 非 final 的 ， 
不 能 保证 clone 方 法 一 定 返回 类 为 java.util.Date 的 对 象 ; 它 有 可 能 返回 专门 出 于 恶意 的 目的 而 
设计 的 不 可 信子 类 的 实例 。 例 如 ， 这 样 的 子 类 可 以 在 每 个 实例 被 创建 的 时 候 ， 把 指向 该 实例 
的 引用 记录 到 一 个 私有 的 静态 列表 中 ， 并 且 允 许 攻 击 者 访问 这 个 列表 。 这 将 使 得 攻击 者 可 以 
自由 地 控制 所 有 的 实例 。 为 了 阻止 这 种 攻击 ， 对 于 参数 类 型 可 以 被 不 可 信任 方 子 类 化 的 参数 ， 
请 不 要 使 用 clone 方 法 进行 保护 性 描 贝 。 


虽然 替换 构造 器 就 可 以 成 功 地 避免 上 述 的 攻击 ， 但 是 改变 Period 实 例 仍然 是 有 可 能 的 ， 
为 它 的 访问 方法 提供 了 对 其 可 变 内 部 成 员 的 访问 能 力 : 

// Second attack on the internals of a Period instance 

Date start = new Date(); 

Date end = new Date(); 


Period p = new Period(start, end); 
p.end().setYear(78); // Modifies internals of p! 


为 了 防御 这 第 二 种 攻击 ， 只 需 修改 这 两 个 访问 方法 ， 使 它 返 回 可 变 内 部 域 的 保护 性 拷贝 
即 可 


// Repaired accessors - make defensive copies of internal fields 
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public Date start() { 


return new Date(start.getTime()); 


public Date end() { 
return new Date(end.getTime()); 


采用 了 新 的 构造 器 和 新 的 访问 方法 之 后 ，Period 真 正 是 不 可 变 的 了 。 不 管 程序 员 是 多 么 恶 
意 ， 或 者 多 么 不 合格 ， 都 绝对 不 会 违反 “周期 的 起 始 时 间 不 能 落后 于 结束 时 间 ” 这 个 约束 条 
件 。 确 实 如 此 ， 因 为 除了 Period 类 自身 之 外 ， 其 他 任何 类 都 无 法 访问 Period 实 例 中 的 任何 一 个 
可 变 域 。 这 些 域 被 真正 封装 在 对 象 的 内 部 。 


访问 方法 与 构造 器 不 同 ， 它 们 在 进行 保护 性 拷贝 的 时 候 允 许 使 用 clone 方 法 。 之 所 以 如 此 ， 
是 因为 我 们 知道 ，Period 内 部 的 Date 对 象 的 类 是 java.util.Date， 而 不 可 能 是 其 他 某 个 潜在 的 不 
可 信子 类 。 也 就 是 说 ， 基 于 第 11 条 中 所 益 述 的 原因 ， 一 般 情况 下 ， 最 好 使 用 构造 器 或 者 静态 
工矿， 


参数 的 保护 性 拷贝 并 不 仅仅 针对 不 可 变 类 。 每 当 编写 方法 或 者 构造 器 时 ， 如 果 它 要 人 允许 客 
户 提 供 的 对 象 进 入 到 内 部 数据 结构 中 ， 则 有 必要 考虑 一 下 ， 客 户 提供 的 对 象 是 否 有 可 能 是 可 
变 的 。 如 果 是 ， 就 要 考虑 你 的 类 是 否 能 够 容忍 对 象 进入 数据 结构 之 后 发 生变 化 。 如 果 答 案 是 
否定 的 ， 就 必须 对 该 对 象 进行 保护 性 拷贝 ， 并 且 让 拷贝 之 后 的 对 象 而 不 是 原始 对 象 进入 到 数 
据 结构 中 。 例 如 ， 如 果 你 正在 考虑 使 用 由 客户 提供 的 对 象 引 用 作为 内 部 Set 实 例 的 元 素 ， 或 者 
作为 内 部 Map 实 例 的 键 (key) ， 就 应 该 意识 到 ， 如 果 这 个 对 象 在 插入 之 后 再 被 修改 ，Set 或 者 
Map 的 约束 条 件 就 会 遭 到 破坏 。 


在 内 部 组 件 被 返回 给 客户 端 之 前 ， 对 它们 进行 保护 性 拷贝 也 是 同样 的 道理 。 不 管 类 是 否 为 
不 可 变 的 ， 在 把 一 个 指向 内 部 可 变 组 件 的 引用 返回 给 客户 端 之 前 ， 也 应 该 加 倍 认真 地 考虑 。 
解决 方案 是 ， 应 该 返回 保护 性 拷贝 。 记 住 长 度 非 零 的 数组 总 是 可 变 的 。 因 此 ， 在 把 内 部 数组 
返回 给 客户 端 之 前 ， 应 该 总 要 进行 保护 性 拷贝 。 另 一 种 解决 方案 是 ， 给 客户 端 返回 该 数组 的 
不 可 变 视 图 (immutable view)。 这 两 种 方法 在 第 13 条 中 都 已 经 演示 过 了 。 


可 以 肯定 地 说 ， 上 述 的 真正 启示 在 于 ， 只 要 有 可 能 ， 都 应 该 使 用 不 可 变 的 对 象 作为 对 象 内 
部 的 组 件 ， 这 样 就 不 必 再 为 保护 性 拷贝 ( 见 第 15 条 ) 操心 。 在 前 面 的 Period 例 子 中 ， 值 得 一 提 
的 是 ， 有 经 验 的 程序 员 通 常 使 用 Date.getTime() 返 回 的 long 基 本 类 型 作为 内 部 的 时 间 表 示 法 ， 
而 不 是 使 用 Date 对 象 引 用 。 他 们 之 所 以 这 样 做 ， 主 要 因为 Date 是 可 变 的 。 


保护 性 拷贝 可 能 会 带 来 相关 的 性 能 损失 ， 这 种 说 法 并 不 总 是 正确 的 。 如 果 类 信任 它 的 调用 
者 不 会 修改 内 部 的 组 件 ， 可 能 因为 类 及 其 客户 端 都 是 同一 个 包 的 双方 ， 那 么 不 进行 保护 性 找 
贝 也 是 可 以 的 。 在 这 种 情况 下 ， 类 的 文档 中 就 必须 清楚 地 说 明 ， 调 用 者 绝 不 能 修改 受到 影响 
的 参数 或 者 返回 值 。 
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即使 跨越 包 的 作用 范围 ， 也 并 不 总 是 适合 在 将 可 变 参 数 整 合 到 对 象 中 之 前 ， 对 它 进 行 保护 
性 拷贝 。 有 一 些 方法 和 构造 器 的 调用 ， 要 求 参数 所 引用 的 对 象 必须 有 个 显 式 的 交接 (handoff) 
过 程 。 当 客户 端 调 用 这 样 的 方法 时 ， 它 承诺 以 后 不 再 直接 修改 该 对 象 。 如 果 方 法 或 者 构造 器 
期 望 接管 一 个 由 客户 端 提供 的 可 变 对 象 ， 它 就 必须 在 文档 中 明确 地 指明 这 一 点 。 


如 果 类 所 包含 的 方法 或 者 构造 器 的 调用 需要 移交 对 象 的 控制 权 ， 这 个 类 就 无 法 让 自身 抵御 
恶意 的 客户 端 。 只 有 当 类 和 它 的 客户 端 之 间 有 着 互相 的 信任 ， 或 者 破坏 类 的 约束 条 件 不 会 伤 
害 到 除了 客户 端 之 外 的 其 他 对 象 时 ， 这 种 类 才 是 可 以 接受 的 。 后 一 种 情形 的 例子 是 包装 类 模 
式 (wrapper class pattern) ( 见 第 16 条 ) 。 根 据 包 装 类 的 本 质 特征 ， 客 户 端 只 需 在 对 象 被 包装 
之 后 直接 访问 它 ， 就 可 以 破坏 包装 类 的 约束 条 件 ， 但是， 这 么 做 往往 只 会 伤害 到 客户 端 自己 。 


简 而 言 之 ， 如 果 类 具有 从 客户 端 得 到 或 者 返回 到 客户 端的 可 变 组 件 ， 类 就 必须 保护 性 地 找 
贝 这 些 组 件 。 如 果 拷 贝 的 成 本 受到 限制 ， 并 且 类 信任 它 的 客户 端 不 会 不 恰当 地 修改 组 件 ， 就 
可 以 在 文档 中 指明 客户 端的 职责 是 不 得 修改 受到 影响 的 组 件 ， 以 此 来 代替 保护 性 拷贝 。 





本 条 目 是 若干 API 设 计 技巧 的 总 结 ， 它 们 都 还 不 足以 单独 开设 一 个 条 目 。 综 合 来 说 ， 这 些 
设计 技巧 将 有 助 于 使 你 的 API 更 易于 学 习 和 使 用 ， 并 且 比 较 不 容易 出 错 。 


谨慎 地 选择 方法 的 名 称 。 方 法 的 名 称 应 该 始终 遵循 标准 的 命名 习惯 ( 见 第 56 条 ) 。 首 要 目 
标 应 该 是 选择 易于 理解 的 ， 并 且 与 同一 个 包 中 的 其 他 名 称 风 格 一 致 的 名 称 。 第 二 个 目标 应 该 
是 选择 与 大 众 认 可 的 名 称 (如 果 存 在 的 话 ) 相 一 致 的 名 称 。 如 果 还 有 疑问 ， 请 参考 Java 类 库 的 
API。 尽 管 Java 类 库 的 API 中 也 有 大 量 不 一 致 的 地 方 ， 考 虑 到 这 些 Java 类 库 的 规模 和 范围 ， 这 
是 不 可 避免 的 ， 但 它 还 是 得 到 了 相当 程度 的 认可 。 


不 要 过 于 追求 提供 便利 的 方法 。 每 个 方法 都 应 该 尽 其 所 能 。 方 法 太 多 会 使 类 难以 学 习 、 使 
用 、 文 档 化 、 测 试 和 维护 。 对 于 接口 而 言 ， 这 无 疑 是 正确 的 ， 方 法 太 多 会 使 接口 实现 者 和 接 
口 用 户 的 工作 变 得 复杂 起 来 。 对 于 类 和 接口 所 支持 的 每 个 动作 ， 都 提供 一 个 功能 齐全 的 方法 。 
只 有 当 一 项 操作 被 经 常用 到 的 时 候 ， 才 考虑 为 它 提供 快捷 方式 (shorthand)。 如 果 不 能 确定 ， 
还 是 不 提供 快捷 为 好 。 


避免 过 长 的 参数 列表 。 目 标 是 四 个 参数 ， 或 者 更 少 。 大 多 数 程序 员 都 无 法 记 住 更 长 的 参数 
列表 。 如 果 你 编写 的 许多 方法 都 超过 了 这 个 限制 ， 你 的 API 就 不 太 便于 使 用 ， 除 非 用 户 不 停 地 
参考 它 的 文档 。 现 代 的 IDE 会 有 所 帮助 ， 但 最 好 还 是 使 用 简短 的 参数 列表 。 相 同类 型 的 长 参数 
序列 格外 有 害 。API 的 用 户 不 仅 无 法 记 住 参数 的 顺序 ， 而 且 ， 当 他 们 不 小 心 弄 错 了 参数 顺序 时 ， 
他 们 的 程序 仍然 可 以 编译 和 运行 ， 只 不 过 这 些 程序 不 会 按照 作者 的 意图 进行 工作 。 


有 三 种 方法 可 以 缩短 过 长 的 参数 列表 。 第 一 种 是 把 方法 分 解 成 多 个 方法 ， 每 个 方法 只 需要 
这 些 参数 的 一 个 子 集 。 如 果 不 小 心 ， 这 样 做 会 导致 方法 过 多 。 但 是 通过 提升 它们 的 正 交 性 
(orthogonality)， 还 可 以 减少 (reduce) 方法 的 数目 。 例 如 ， 考 虑 java.util.List 接 口 。 它 并 没 
有 提供 “在 子 列表 (sublist) 中 查找 元 素 的 第 一 个 索引 和 最 后 一 个 索引 ”的 方法 ， 这 两 个 方法 
都 需要 三 个 参数 。 相 反 ， 它 提供 了 subList 方 法 ， 这 个 方法 带 有 两 个 参数 ， 并 返回 子 列表 的 一 
个 视图 (view)。 这 个 方法 可 以 与 :ndexOf 或 者 lastIndexOf 方 法 结合 起 来 ， 获 得 期 望 的 功能 ， 
而 这 两 个 方法 都 分 别 只 有 一 个 参数 。 而 且 ，subList 方 法 也 可 以 与 其 他 任何 “针对 List 实 例 进行 
操作 ”的 方法 结合 起 来 ， 在 子 列表 上 执行 任意 的 计算 。 这 样 得 到 的 API 就 有 很 高 的 “功能 一 重 
量 ”(power-to-weight) 比 。 


缩短 长 参数 列表 的 第 二 种 方法 是 创建 辅助 类 (helper class) ， 用 来 保存 参数 的 分 组 。 这 些 
辅助 类 一 般 为 静态 成 员 类 ( 见 第 22 条 ) 。 如 果 一 个 频繁 出 现 的 参数 序列 可 以 被 看 作 是 代表 了 某 
个 独特 的 实体 ， 则 建议 使 用 这 种 方法 。 例 如 ， 假 设 你 正在 编写 一 个 表示 纸牌 游戏 的 类 ， 你 会 
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发 现 ， 经 常 要 传递 一 个 两 参数 的 序列 来 表示 纸牌 的 点 数 和 花色 。 如 果 增 加 辅助 类 来 表示 一 张 
纸牌 ， 并 且 把 每 个 参数 序列 都 换 成 这 个 辅助 类 的 单个 参数 ， 那 么 这 个 纸牌 游戏 类 的 API 以 及 它 
的 内 部 表示 都 可 能 会 得 到 改进 。 


结合 了 前 两 种 方法 特征 的 第 三 种 方法 是 ， 从 对 象 构建 到 方法 调用 都 采用 Builder 模 式 (请 
见 第 2 条 ) 。 如 果 方 法 带 有 多 个 参数 ， 尤 其 是 当 它 们 中 有 些 是 可 选 的 时 候 ， 最 好 定义 一 个 对 象 
来 表示 所 有 参数 ， 并 允许 客户 端 在 这 个 对 象 上 进行 多 次 “setter” 调 用 ， 每 次 调用 都 设置 一 个 
参数 ， 或 者 设置 一 个 较 小 的 相关 的 集合 。 一 旦 设置 了 需要 的 参数 ， 客 户 端 就 调用 对 象 的 “ 执 
{F (execute)” 方 法 ， 它 对 参数 进行 最 终 的 有 效 性 检查 ， 并 执行 实际 的 计算 。 


对 于 参数 类 型 ， 要 优先 使 用 接口 而 不 是 类 (请 见 第 52 条 )。 只 要 有 适当 的 接口 可 用 来 定义 
参数 ， 就 优先 使 用 这 个 接口 ， 而 不 是 使 用 实现 该 接口 的 类 。 例 如 ， 没 有 理由 在 编写 方法 时 使 
用 HashMap 类 来 作为 输入 ， 相 反 ， 应当 使 用 Map 接 口 作 为 参数 。 这 使 你 可 以 传人 一 个 
Hashtable、HashMap、TreeMap、TreeMap 的 子 映射 表 (submap) ， 或 者 任何 有 待 于 将 来 编写 
的 Map 实 现 。 如 果 使 用 的 是 类 而 不 是 接口 ， 则 限制 了 客户 端 只 能 传人 特定 的 实现 ， 如 果 碰 巧 输 
入 的 数据 是 以 其 他 的 形式 存在 ， 就 会 导致 不 必要 的 、 可 能 非常 昂贵 的 拷贝 操作 。 


对 于 boolean 参 数 ， 要 优先 使 用 两 个 元 素 的 枚 举 类 型 。 它 使 代码 更 易于 阅读 和 编写 ， 尤 其 
当 你 在 使 用 支持 自动 完成 功能 的 IDE 的 时 候 。 它 也 使 以 后 更 易于 添加 更 多 的 选项 。 例 如 ， 你 可 
能 会 有 一 个 Thermometer 类 型 ， 它 带 有 一 个 静态 工厂 方法 ， 而 这 个 静态 工厂 方法 的 签名 需要 传 
入 这 个 枚 举 的 值 : 


public enum TemperatureScale { FAHRENHEIT, CELSIUS } 


Thermometer.newInstance(TemperatureScale.CELSIUS) 不 仅 比 Thermometer.newInstance 
(true) 更 有 用 ， 而且 你 还 可 以 在 未 来 的 发 行 版 本 中 将 KELVIN 添 加 到 TemperatureScale 中 ， 无 需 
非得 给 Thermometer 添 加 新 的 静态 工厂 。 你 还 可 以 将 依赖 于 温度 刻度 单位 的 代码 重 构 到 枚 举 常 
量 的 方法 中 ( 见 第 30 条 ) 。 例 如 ， 每 个 刻度 单位 都 可 以 有 一 个 方法 ,， 它 带 有 一 个 double 值 , 并 . 
将 它 规格 化 成 摄氏 度 。 


Bins 165 





下 面 这 个 程序 的 意图 是 好 的 ， 它 试图 根据 一 个 集合 (collection) 是 Set、List， 还 是 其 他 
的 集合 类 型 ， 来 对 它 进行 分 类 : 


// Broken! - What does this program print? 
public class CollectionClassifier { 
public static String classify(Set<?> s) { 
return "Set"; 
} 
public static String classify(List<?> Ist) { 
return "List"; 


public static String classify(Collection<?> c) { 
return "Unknown Collection"; i 


public static void main(String[] args) { 
Collection<?>[] collections = { 
new HashSet<String>(), 
new ArrayList<BigInteger>(), 
new HashMap<String, String>().values() 


for (Collection<?> c : collections) 
System.out.println(classify(c)); 
} 


} 


你 可 能 期 望 这 个 程序 会 打印 出 “Set”， 紧 接着 是 “List?， 以 及 “Unknown Collection”, 
但 实际 上 不 是 这 样 。 它 是 打印 “Unknown Collection” 三 次 。 为 什么 会 这 样 呢 ? 因为 classify 
方法 被 重 载 (overloaded) 了 ， 而 要 调用 哪个 重 载 (overloading) 方法 是 在 编译 时 做 出 决定 
的 。 对 于 for 循 环 中 的 全 部 三 次 迭代 ， 参 数 的 编译 时 类 型 都 是 相同 的 : Collection<?>, ik 
代 的 运行 时 类 型 都 是 不 同 的 ， 但 这 并 不 影响 对 重 载 方法 的 选择 。 因 为 该 参数 的 编译 时 类 型 为 
Collection<?>， 所 以 ， 唯 一 合适 的 重 载 方 法 是 第 三 个 : classify(Collection<?>)， 在 循环 的 每 
HEH, MBA eT BATE. 


这 个 程序 的 行为 有 悖 常理 ， 因 为 对 于 重 载 方 法 (overloaded method) 的 选择 是 静态 的 ， 
而 对 于 被 覆盖 的 方法 (overridden method) 的 选择 则 是 动态 的 。 选 择 被 履 盖 的 方法 的 正确 版 
本 是 在 运行 时 进行 的 ， 选 择 的 依据 是 被 调用 方法 所 在 对 象 的 运行 时 类 型 。 这 里 重新 说 明 一 下 ， 
当 一 个 子 类 包含 的 方法 声明 与 其 祖先 类 中 的 方法 声明 具有 同样 的 签名 时 ， 方 法 就 被 覆盖 了 。 
如 果实 例 方法 在 子 类 中 被 覆盖 了 ， 并 且 这 个 方法 是 在 该 子 类 的 实例 上 被 调用 的 ， 那么 子 类 中 
的 和 覆盖 方法 (overriding method) 将 会 执行 ， 而 不 管 该 子 类 实例 的 编译 时 类 型 到 底 是 什么 。 
为 了 进行 更 具体 的 说 明 ， 考 虑 下 面 这 个 程序 : 
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class Wine { 
String name() { return "wine"; } ` 


class SparklingWine extends Wine { 
@Override String name() { return “sparkling wine"; } 
} 


class Champagne extends SparklingWine { 
@Override String name() { return "champagne"; } 
} 


public class Overriding { 
public static void main(String[] args) { 
Wine[] wines = { 
j new Wine(), new SparklingWine(), new Champagne() 


for (Wine wine : wines) 
System.out.printIn(wine.name()); 
} 


} 


name 方 法 是 在 类 Wine 中 被 声明 的 ， 但 是 在 类 SparklingWine 和 Champagne 中 被 覆盖 。 正 如 
你 所 预期 的 那样 ， 这 个 程序 打印 出 “wine，sparkling wine 和 champagne"， 尽 管 在 循环 的 每 次 
迭 代 中 ， 实 例 的 编译 时 类 型 都 为 Wine。 当 调用 被 覆盖 的 方法 时 ， 对 象 的 编译 时 类 型 不 会 影响 
到 哪个 方法 将 被 执行 ，“ 最 为 具体 的 (most specific) ”那个 覆盖 版 本 总 是 会 得 到 执行 。 这 与 
重 载 的 情形 相 比 ， 对 象 的 运行 时 类 型 并 不 影响 “哪个 重 载 版 本 将 被 执行 ”， 选择 工作 是 在 编 
译 时 进行 的 ， 完 全 基于 参数 的 编译 时 类 型 。 


在 CollectionClassifier 这 个 示例 中 ， 该 程序 的 意图 是 : 期 望 编译 器 根据 参数 的 运行 时 类 型 
自动 将 调用 分 发 给 适当 的 重 载 方 法 ， 以 此 来 识别 出 参数 的 类 型 ， 就 好 像 Wine 的 例子 中 的 name 
方法 所 做 的 那样 。 方 法 重 载 机 制 完 全 没有 提供 这 样 的 功能 。 假 设 需要 有 个 静态 方法 ， 这 个 程 
序 的 最 佳 修 正方 案 是 ， 用 单个 方法 来 替换 这 三 个 重 载 的 classify 方 法 ， 并 在 这 个 方法 中 做 一 个 
显 式 的 instanceof 测 试 : 


public static String classify(Collection<?> c) { 
return c instanceof Set ? "Set" : 
c instanceof List ? "List" : “Unknown Collection"; 


} 


因为 覆盖 机 制 是 规范 ， 而 重 载 机 制 是 例外 ， 所 以 ， 覆 盖 机 制 满足 了 人 们 对 于 方法 调用 行为 
的 期 望 。 正 如 CollectionClassifier 例 子 所 示 ， 重 载 机 制 很 容易 使 这 些 期 望 落空 。 如 果 编 写 出 来 
的 代码 的 行为 可 能 使 程序 员 感 到 困惑 ， 它 就 是 很 糟糕 的 实践 。 对 于 API 来 说 尤其 如 此 。 如 果 
API 的 普通 用 户 根本 不 知道 “对 于 一 组 给 定 的 参数 ， 其 中 的 哪个 重 载 方法 将 会 被 调用 ”"， 那 么 ， 
使 用 这 样 的 API 就 很 可 能 导致 错误 。 这 些 错 误 要 等 到 运行 时 发 生 了 怪异 的 行为 之 后 才 会 显现 出 
来 ,许多 程序 员 无 法 诊断 出 这 样 的 错误 。 因 此 ， 应 该 避免 胡乱 地 使 用 重 载 机 制 。 


到 底 怎样 才 算 胡乱 使 用 重 载 机 制 呢 ? 这 个 问题 仍 有 和 争议。 安全 而 保守 的 策略 是 ， 永 远 不 要 
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导出 两 个 具有 相同 参数 数目 的 重 载 方法 。 如 果 方 法 使 用 可 变 参数 《varargs)， 保 守 的 策略 是 
根本 不 要 重 载 它 ， 除 第 42 条 中 所 述 的 情形 之 外 。 如 果 你 遵守 这 些 限制 ， 程 序 员 永远 也 不 会 陷 
入 到 “对 于 任何 -组 实际 的 参数 ， 哪 个 重 载 方法 是 适用 的 ”这 样 的 疑问 中 。 这 项 限制 并 不 麻 
烦 ， 因 为 你 始终 可 以 给 方法 起 不 同 的 名 称 ， 而 不 使 用 重 载 机 制 。 


例如 ， 考 虑 ObjectOutputStream 类 。 对 于 每 个 基本 类 型 ， 以 及 几 种 引用 类 型 ， 它 的 write 方 
法 都 有 一 种 变形 。 这 些 变形 方法 并 不 是 重 载 write 方法 ， 而 是 具有 诸如 writeBoolean(boolean)、 
writeInttinb 和 writeLong(long) 这 样 的 签名 。 与 重 载 方案 相 比较 ， 这 种 命名 模式 带 来 的 好 处 是 ， 
有 可 能 提供 相应 名 称 的 读 方法 ， 比 如 readBoolean()、 readInt() 和 readLong()。 实 际 上 ， 
ObjectInputStream 类 正 是 提供 了 这 样 的 读 方法 。 


对 于 构造 器 ， 你 没有 选择 使 用 不 同名 称 的 机 会 ， 一 个 类 的 多 个 构造 器 总 是 重 载 的 。 在 许多 
情况 下 ， 可 以 选择 导出 静态 工厂 ， 而 不 是 构造 器 〈( 见 第 1 条 ) 。 对 于 构造 器 ， 还 不 用 担心 重 载 
和 覆盖 的 相互 影响 ， 因 为 构造 器 不 可 能 被 覆盖 。 或 许 你 有 可 能 导出 多 个 具有 相同 参数 数目 的 
构造 器 ， 所 以 有 必要 了 解 一 下 如 何 安全 地 做 到 这 一 点 。 


如 果 对 于 “任何 一 组 给 定 的 实际 参数 将 应 用 于 哪个 重 载 方法 上 ”始终 非常 清楚 ， 那 么 ， 导 
出 多 个 具有 相同 参数 数目 的 重 载 方法 就 不 可 能 使 程序 员 感到 混淆 。 如 果 对 于 每 一 对 重 载 方法 ， 
至 少 有 一 个 对 应 的 参数 在 两 个 重 载 方法 中 具有 “根本 不 同 (radically different)” 的 类 型 ， 就 
属于 这 种 情形 。 如 果 显 然 不 可 能 把 一 种 类 型 的 实例 转换 为 另 一 种 类 型 ， 这 两 种 类 型 就 是 根本 
不 同 的 。 在 这 种 情况 下 ， 一 组 给 定 的 实际 参数 应 用 于 哪个 重 载 方法 上 就 完全 由 参数 的 运行 时 
类 型 来 决定 ， 不 可 能 受到 其 编译 时 类 型 的 影响 ， 所 以 主要 的 混 清 根源 就 消除 了 。 例 如 ， 
ArrayList 有 一 个 构造 器 带 一 个 int 参 数 ， 另 一 个 构 造 器 带 一 个 Collection 参 数 。 难 以 想像 在 什么 
情况 下 ， 会 不 清楚 要 调用 哪 一 个 构造 器 。 


在 Java 1.5 发 行 版 本 之 前 ， 所 有 的 基本 类 型 都 根本 不 同 于 所 有 的 引用 类 型 ， 但 是 当 自动 装 
箱 出 现 之 后 ， 就 不 再 如 此 了 ， 它 会 导致 真正 的 麻烦 。 考 虑 下 面 这 个 程序 : 


public class SetList { 
public static void main(String[] args) { 
Set<Integer> set = new TreeSet<Integer>Q ; 
List<Integer> list = new ArrayList<Integer>(); 


for Cint i = -3; i < 3; i++) { 
set.add(i); 
list.add(i); 

for Cint i = 0; i < 3; i++) { 
set. remove(i); 
list. remove(i); 


System.out.printin(set + " " + list); 
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程序 将 一 3 至 2 之 间 的 整数 添加 到 了 排 好 序 的 集合 和 列表 中 ， 然 后 在 集合 和 列表 中 都 进行 3 
次 相同 的 remove 调 用 。 如 果 像 大 多 数 人 人 一样， 希望 程序 从 集合 和 列表 中 去 除非 整数 值 (0, 1 
和 2)， 并 打印 出 [一 3， 一 2， 一 1] [一 3， 一 2， 一 1]。 事 实 上 ， 程 序 从 集合 中 去 除了 非 整 数 ， 
还 从 列表 中 去 除了 奇数 值 ， 打 印 出 [一 3， 一 2， 一 1] [一 2，0，2]。 将 这 种 行为 称 之 为 混乱 ， 已 
是 保守 的 说 法 。 


实际 发 生 的 情况 是 ，set.remove(i) 调 用 选择 重 载 方法 remove(E)， 这 里 的 E 是 集合 (Integer) 
的 元 素 类 型 ， 将 i 从 int 自 动 装 箱 到 Integer 中 。 这 是 你 所 期 待 的 行为 ， 因 此 程序 不 会 从 集合 中 去 
除 正 值 。 另 一 方面 ，list.remove(i) 调 用 选择 重 载 方法 remove(int i)， 它 从 列表 的 指定 位 置 上 去 
除 元 素 。 如 果 从 列表 [一 3， 一 2， 一 1，0，1，2] 开 始 ， 去 除 第 零 个 元 素 ， 接 着 去 除 第 一 个 、 第 
二 个 ， 得 到 的 是 [一 2，0，2]， 这 个 秘密 被 揭 开 了 。 为 了 解决 这 个 问题 ， 要 将 list.remove 的 参数 
转换 成 Integer， 迫 使 选择 正确 的 重 载 方法 。 另 一 种 方法 是 ， 可 以 调用 Integer.valueOf(i)， 并 将 
结果 传 给 listremove。 这 两 种 方法 都 如 我 们 所 料 ， 打 印 出 [-3，-2，-1] 1-3, -2, —i]: 

for Cint i= 0; i < 3; i++) { 


set.remove(i); 
list.remove((Integer) i); // or remove(Integer.valueOf(i)) 


前 一 个 范例 中 所 示 的 混乱 行为 在 这 里 也 出 现 了 ， 因 为 List<E> 接 口 有 两 个 重 载 的 remove 方 
法 : remove(E) 和 remove(int)。 当 它 在 Java 1.5 发 行 版 本 中 被 泛 型 化 之 前 ，List 接 口 有 一 个 
remove(Object) 而 不 是 remove(E)， 相 应 的 参数 类 型 ， Object 和 int， 则 根本 不 同 。 但 是 自从 有 
了 泛 型 和 自动 装 箱 之 后 ， 这 两 种 参数 类 型 就 不 再 根本 不 同 了 。 换 句 话 说 ，Java 语 言 中 添加 了 泛 
型 和 自动 装 箱 之 后 ， 破 坏 了 List 接 口 。 幸 运 的 是 ，Java 类 库 中 几乎 再 没有 API 受 到 同样 的 破坏 ， 
但 是 这 种 情形 清楚 地 说 明了 ， 自 动 装 箱 和 泛 型 成 了 Java 语 言 的 一 部 分 之 后 ， 谨 慎重 载 显 得 更 加 
重要 了 。 


数组 类 型 和 Object 之 外 的 类 截然 不 同 。 数 组 类 型 和 Serializable 与 Cloneable 之 外 的 接口 也 
截然 不 同 。 如 果 两 个 类 都 不 是 对 方 的 后 代 ， 这 两 个 独特 的 类 就 是 不 相关 的 (unrelated) [JLS， 
5.5]。 例 如 ，String 和 Throwable 就 是 不 相关 的 。 任 何 对 象 都 不 可 能 是 两 个 不 相关 的 类 的 实例 ， 
因此 不 相关 的 类 是 根本 不 同 的 。 


还 有 其 他 一 些 “ 类 型 对 ”的 例子 也 是 不 能 相互 转换 的 [JLS, 5.1.12]， 但 是 ,一旦 超出 了 上 
述 这 些 简单 的 情形 ， 大 多 数 程序 员 要 想 搞 清楚 “一 组 实际 的 参数 应 用 于 哪个 重 载 方 法 上 ”就 
会 非常 困难 。 确 定 选择 哪个 重 载 方法 的 规则 是 非常 复杂 的 。 这 些 规则 在 语言 规范 中 占 了 33 页 
的 篇 幅 [JLS, 15.12.1-3]， 很 少 有 程序 员 能 够 理解 其 中 的 所 有 微妙 之 处 。 


有 了 时候， 尤其 在 更 新 现 有 类 的 时 候 ， 可 能 会 被 迫 违反 本 条 目的 指导 原则 。 例 如 ， 自 从 Java 
1.4 发 行 版 本 以 来 ，String 类 就 已 经 有 一 个 contentEquals (StringBuffer) 方法 。 在 Java 1.5 发 行 
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版 本 中 ， 新 增 了 一 个 称 作 CharSequence 的 接口 ， 用 来 为 StringBuffer、StringBuilder、String、 
CharBuffer 以 及 其 他 类 似 的 类 型 提供 公共 接口 ， 为 实现 这 个 接口 ， 对 它们 全 都 进行 了 改造 。 在 
Java 平 台中 增加 CharSequence 的 同时 ，String 也 配备 了 重 载 的 contentEquals 方 法 ， 即 content 
Equals (CharSequence) 方法 ， 这 个 方法 表示 ， 当 且 仅 当 此 String 表 示 与 CharSequence 序 列 相 
同 的 char 值 时 ， 返 回 true。 


尽管 这 样 的 重 载 很 显然 违反 了 本 条 目的 指导 原则 ， 但 是 只 要 当 这 两 个 重 载 方法 在 同样 的 参 
数 上 被 调用 时 ， 它 们 执行 相同 的 功能 ， 重 载 就 不 会 带 来 危害 。 程 序 员 可 能 并 不 知道 哪个 重 载 
函数 会 被 调用 ， 但 只 要 这 两 个 方法 返回 相同 的 结果 就 行 。 确 保 这 种 行为 的 标准 做 法 是 ， 让 更 
具体 化 的 重 载 方法 把 调用 转发 给 更 一 般 化 的 重 载 方法 : 


public boolean contentEquals(StringBuffer sb) { 
return contentEquals((CharSequence) sb); 


虽然 Java 平 台 类 库 很 大 程度 上 遵循 了 本 条 目 中 的 建议 ， 但 是 也 有 诸多 的 类 违背 了 。 例 如 ， 
String 类 导出 两 个 重 载 的 静态 工厂 方法 : valueOf(char[]) 和 valueOf(Object)， 当 这 两 个 方法 被 
传递 了 同样 的 对 象 引 用 时 ， 它 们 所 做 的 事情 完全 不 同 。 没 有 正当 的 理由 可 以 解释 这 一 点 ， 它 
应 该 被 看 作 是 一 种 反常 行为 ， 有 可 能 会 造成 真正 的 混淆。 


简 而 言 之 , “能够 重 载 方法 ”并 不 意味 着 就 “应 该 重 载 方法 ”。 一 般 情况 下 ， 对 于 多 个 具 
有 相同 参数 数目 的 方法 来 说 ， 应 该 尽量 避免 重 载 方法 。 在 某 些 情况 下 ， 特 别 是 涉及 构造 器 的 
时 候 ， 要 遵循 这 条 建议 也 许 是 不 可 能 的 。 在 这 种 情况 下 ， 至 少 应 该 避免 这 样 的 情形 : 同一 组 
参数 只 需 经 过 类 型 转换 就 可 以 被 传递 给 不 同 的 重 载 方法 。 如 果 不 能 避免 这 种 情形 ， 例 如 ， 因 
为 正在 改造 一 个 现 有 的 类 以 实现 新 的 接口 ， 就 应 该 保证 : 当 传 递 同样 的 参数 时 ， 所 有 重 载 方 
法 的 行为 必须 一 致 。 如 果 不 能 做 到 这 一 点 ， 程 序 员 就 很 难 有 效 地 使 用 被 重 载 的 方法 或 者 构造 
器 ， 他 们 就 不 能 理解 它 为 什么 不 能 正常 地 工作 。 
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Java 1.5 发 行 版 本 中 增加 了 可 变 参 数 (varargs) 方法 ， 一 般 称 作 variable arity method 
(可 匹配 不 同 长 度 的 变量 的 方法 ) [JLS，8.4.1]。 可 变 参数 方法 接受 0 个 或 者 多 个 指定 类 型 的 参 
数 。 可 变 参数 机 制 通过 先 创建 一 个 数组 ， 数 组 的 大 小 为 在 调用 位 置 所 传递 的 参数 数量 ， 然 后 
将 参数 值 传 到 数组 中 ， 最 后 将 数组 传递 给 方法 。 


例如 ， 下 面 就 是 一 个 可 变 参数 方法 ， 带 有 int 参 数 的 一 个 序列 ， 并 返回 它们 的 总 和 。 正 如 
你 所 期 望 的 ，sum(1, 2, 3) 的 值 为 6，sum() 的 值 为 0: 


// Simple use of varargs 
static int sum(int... args) { 
int sum = 0; 
for (int arg : args) 
sum += arg; 
return sum; 


有 时 候 ， 有 必要 编写 需要 1 个 或 者 多 个 某 种 类 型 参数 的 方法 ， 而 不 是 需要 0 个 或 者 多 个 。 
例如 ， 假 设想 要 计算 多 个 int 参 数 的 最 小 值 。 如 果 客 户 端 没 有 传递 参数 ， 那 这 个 方法 的 定义 就 
不 太 好 了 。 你 可 以 在 运行 时 检查 数组 长 度 : 


// The WRONG way to use varargs to pass one or more en 
static int min(int... args) { 
if (args.length == 0) 
throw new I] legalArgumentException("Too few arguments"); 
int min = args[0]; 
for (int i = 1; i < args.length; i++) 
if (args[i] < min) 
min = args[i]; 
return min; 


} 


这 种 解决 方案 有 几 个 问题 。 其 中 最 严重 的 问题 是 ， 如 果 客 户 端 调用 这 个 方法 时 ， 并 没有 传 
递 参数 进去 ， 它 就 会 在 运行 时 而 不 是 编译 时 失败 。 另 一 个 问题 是 ， 这 上段 代码 很 不 美观 。 你 必 
须 在 args 中 包含 显 式 的 有 效 性 检查 ， 除 非 将 min 初 始 化 为 Integer.MAX_VALUE， 否 则 将 无 法 使 
用 for-each 循 环 ， 这 样 的 代码 也 不 美观 。 


幸运 的 是 ， 有 一 种 更 好 的 方法 可 以 实现 想 要 的 这 种 效果 。 声 明 该 方法 带 有 两 个 参数 ， 一 
是 指定 类 型 的 正常 参数 ， 另 一 个 是 这 种 类 型 的 varargs 参 数 。 这 种 解决 方案 解决 了 前 一 个 示例 
中 的 所 有 不 足 : 


// The right way to use varargs to pass one or more arguments 
static int min(int firstArg, int... remainingArgs) { 
int min = firstArg; 
for (Cint arg : remainingArgs) 
if (arg < min) 
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min = arg; 
return min; 


如 你 所 见 ， 当 你 真正 需要 让 一 个 方法 带 有 不 定数 量 的 参数 时 ， 可 变 参数 就 非常 有 效 。 可 变 
参数 是 为 printf 而 设计 的 ， 它 是 在 Java 1.5 发 行 版 本 中 添加 到 平台 中 的 ， 为 了 核心 的 反射 机 制 
( 见 第 53 条 ) ， 在 该 发 行 版 本 中 被 改造 成 利用 可 变 参 数 。printf 和 反射 机 制 都 从 可 变 参数 中 极 大 
地 受益 。 


可 以 将 以 数组 当 作 final 参 数 的 现 有 方法 , 改造 成 以 可 变 参 数 代替 , 而 不 影响 现 有 的 客户 端 。 
但 是 可 以 并 不 意味 着 应 该 这 么 做 ! 考虑 Arrays.asList 的 情形 。 这 个 方法 从 来 都 不 是 设计 成 用 来 
将 多 个 参数 集中 到 一 个 列表 中 的 ， 但 是 当 平台 中 增加 了 可 变 参 数 时 ， 将 它 改 造成 这 么 做 似乎 
是 个 好 办 法 。 因 此 ， 变 成 可 以 这 样 : 


List<String> homophones = Arrays.asList("to", "too", "two"); 


这 种 用 法 有 效 ， 但 是 这 么 用 就 是 个 大 错误 。 在 Java 1.5 发 行 版 本 之 前 ， 打 印 数 组 内 容 的 常 
见 做 法 如 下 : 


// Obsolete idiom to print an array! 
System.out.printin(Arrays.asList(myArray)) ; 


这 种 做 法 在 当时 是 必需 的 ， 因 为 数组 从 Object 继承 了 它们 的 toString 实 现 ， 因 此 直接 在 数 
组 上 调用 toString， 会 产生 没有 意义 的 字符 串 ， 如 [Ljava.lang.Integer;@3e25a5 。 这 种 做 法 只 
在 对 象 引 用 类 型 的 数组 上 才 有 用 ， 但 是 如 果 不 小 心 在 基本 类 型 的 数组 上 尝试 这 么 做 ， 程 序 将 
无 法 编译 。 例 如 ， 这 个 程序 : 


public static void main(String[] args) { 
int[] digits = { 3, 1, 4, 1, -Sa a, 6, 5, 4 }; 
System.out. printIn(Arrays. asList(digits)); 

} 


在 发 行 版 本 1.4 中 ， 这 个 程序 会 产生 这 条 错误 消息 : 


Va.java:6: asList(Object[]) in Arrays can't be applied to (int[]) 
System.out.printIn(Arrays.asList(digits)); 
A 


由 于 在 Java 1.5 发 行 版 本 中 ， 令 人 遗憾 地 决定 将 Arrays.asList 改 造成 可 变 参 数 方法 ， 现 在 
这 个 程序 可 以 通过 编译 ， 并 且 没 有 错误 或 者 警告 。 但 是 运行 这 个 程序 时 ， 会 输出 无 意识 的 也 
是 无 意义 的 结果 : [LI@3e25a5]。Arrays.asList 方 法 现在 “增强 ”为 使 用 可 变 参数 ， 将 int 类 型 
的 数组 digits 的 对 象 引 用 集中 到 数组 的 单个 元 素数 组 中 ， 并 忠实 地 将 它 包 装 到 List<int[]> 实 例 
中 。 打 印 这 个 列表 会 导致 在 列表 中 调用 toString ， 从 而 导致 在 它 唯 一 的 元 素 int 数 组 上 调用 
toString， 产 生 上 述 令 人 遗憾 的 结果 。 
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从 好 的 方面 看 ， 将 数组 转变 成 字符 串 的 Arrays.asList 做 法 现在 是 过 时 的 ， 当 前 的 做 法 要 健 
壮 得 多 。 也 是 在 Java 1.5 发 行 版 本 中 ，Arrays 类 得 到 了 补充 完整 的 Arrays.toString 方 法 (不 是 
可 变 参 数 方法 ! )， 专 门 为 了 将 任何 类 型 的 数组 转变 成 字符 串 而 设计 的 。 如 果 用 Arrays.to 
String ft #Arrays.asList, 这 个 程序 就 会 产生 想 要 的 结果 : 

// The right way to print an array 

System.out.println(Arrays.toString(myArray)); 

如 果 不 改 造 Arrays.asList， 更 好 的 办 法 则 是 给 Collections 添 加 一 个 新 的 方法 ， 专 门 用 来 将 
它 的 参数 集中 到 列表 中 : 


public static <T> List<T> gather(T... args) { 
return Arrays.asList(args); 


这 种 方法 可 以 提供 收集 功能 ， 而 不 会 危及 对 现 有 Arrays.asList 方 法 的 类 型 检查 。 


这 个 教训 很 明显 。 不 必 改 造 具有 final 数 组 参数 的 每 个 方法 ; 只 当 确 实 是 在 数量 不 定 的 值 
上 执行 调用 时 才 使 用 可 变 参数 。 


有 两 个 方法 签名 特别 可 疑 ， 


ReturnTypel suspectl(Object... args) { } 
<T> ReturnType2 suspect2(T... args) { } 


带 有 上 述 任何 一 种 签名 的 方法 都 可 以 接受 任何 参数 列表 。 改 造 之 前 进行 的 任何 编译 时 的 类 
型 检查 都 会 丢失 ，Arrays.asList 发 生 的 情形 正 是 说 明了 这 一 点 。 


在 重视 性 能 的 情况 下 ， 使 用 可 变 参数 机 制 要 特别 小 心 。 可 变 参 数 方法 的 每 次 调用 都 会 导致 
进行 一 次 数组 分 配 和 初始 化 。 如 果 赁 经 验 确定 无 法 承受 这 一 成 本 ， 但 又 需要 可 变 参 数 的 灵活 
性 ， 还 有 一 种 模式 可 以 让 你 如 愿 以 偿 。 假 设 确 定 对 某 个 方法 95% 的 调用 会 有 3 个 或 者 更 少 的 参 
数 ， 就 声明 该 方法 的 5 个 重 载 ， 每 个 重 载 方法 带 有 0 至 3 个 普通 参数 ， 当 参数 的 数目 超过 3 个 时 ， 
就 使 用 一 个 可 变 参数 方法 : 

public void foo() { } 

public void foo(int al) { } 

public void foo(int al, int a2) { } 


public void foo(int al, int a2, int a3) { } 
public void foo(int al, int a2, int a3, int... rest) {} 


现在 你 知道 了 ， 所 有 调用 中 只 有 5% 参 数 数量 超过 3 个 的 调用 需要 创建 数组 。 就 像 大 多 数 的 
性 能 优化 一 样 ， 这 种 方法 通常 不 太 恰 当 ， 但 是 一 旦 真正 需要 它 时 ， 它 可 就 帮 上 大 忙 了 。 


EnumSet 类 对 它 的 静态 工厂 使 用 这 种 方法 ， 最 大 限度 地 减少 创建 枚 举 集合 的 成 本 。 当 时 这 
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么 做 是 有 必要 的 ， 因 为 枚 举 集合 为 位 域 提供 在 性 能 方面 有 竞争 力 的 替代 方法 ， 这 是 很 重要 的 
( 见 第 32 条 )。 


简 而 言 之 ， 在 定义 参数 数目 不 定 的 方法 时 ， 可 变 参数 方法 是 一 种 很 方便 的 方式 ,但 是 它们 
不 应 该 被 过 度 滥用 。 如 果 使 用 不 当 ， 会 产生 混乱 的 结果 。 
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像 下 面 这 样 的 方法 并 不 少见 : 


private final List<Cheese> cheesesInStock = ...; 
[ue 
+ @return an array containing all of the cheeses in the shop, 
* or null if no cheeses are available for pe 
public Cheese[] getCheeses() { 
if (cheesesInStock.size() == 0) 
return null; 


} 


FEY A WAR (cheese) 可 买 的 情况 当 作 是 一 种 特例 ， 这 是 不 合 常理 的 。 这 样 做 会 要 求 客户 
端 中 必须 有 额外 的 代码 来 处 理 null 返 回 值 ， 例 如 : 

Cheese[] cheeses = shop.getCheeses(); 

if (cheeses != null 


Arrays.asList(cheeses) .contains(Cheese.STILTON)) 
System.out.printin("Jolly good, just the thing."); 


而 不 是 下 面 这 段 代码 : 


if (Arrays.asList(shop.getCheeses()).contains(Cheese.STILTON)) 
System.out.printin("Jolly good, just the thing."); 

对 于 一 个 返回 null 而 不 是 零 长 度数 组 或 者 集合 的 方法 ， 几 乎 每 次 用 到 该 方法 时 都 需要 这 种 
曲折 的 处 理 方式 。 这 样 做 很 容易 出 错 ， 因 为 编写 客户 端 程序 的 程序 员 可 能 会 忘记 写 这 种 专门 
的 代码 来 处 理 null 返 回 值 。 这 样 的 错误 也 许 几 年 都 不 会 被 注意 到 ， 因 为 这 样 的 方法 通常 返回 一 
个 或 者 多 个 对 象 。 返回 null 而 不 是 零 长 度 的 数组 也 会 使 返回 数组 或 者 集合 的 方法 本 身 变 得 更 加 
复杂 ， 这 一 点 虽然 不 是 特别 重要 ， 但 是 也 值得 注意 。 


有 时 候 会 有 人 认为 : null 返 回 值 比 零 长 度数 组 更 好 ， 因 为 它 避 免 了 分 配 数组 所 需要 的 开销 。 
这 种 观点 是 站 不 住 脚 的 ， 原 因 有 两 点 。 第 一 ， 在 这 个 级 别 上 担心 性 能 问题 是 不 明智 的 ， 除 非 
分 析 表 明 这 个 方法 正 是 造成 性 能 问题 的 真正 源头 ( 见 第 55 条 ) 。 第 二 ， 对 于 不 返回 任何 元 素 的 
调用 ， 每 次 都 返回 同一 个 零 长 度数 组 是 有 可 能 的 ， 因 为 零 长 度数 组 是 不 可 变 的 ， 而 不 可 变 对 
象 有 可 能 被 自由 地 共享 ( 见 第 15 条 ) 。 实 际 上 ， 当 你 使 用 标准 做 法 (standard idiom) 把 一 些 
元 素 从 一 个 集合 转 存 到 一 个 类 型 化 的 数组 (typed array) 中 时 ， 它 正 是 这 样 做 的 : 


// The right way to return an array from a collection 
private final List<Cheese> cheesesInStock = ...; 


private static final Cheese[] EMPTY_CHEESE_ARRAY = new Cheese[0]; 
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[+*+ : 
+ @return an array containing all of the cheeses in the shop. 


*/ 
public Cheese[] getCheeses() { 
return cheesesInStock .toArray(EMPTY_CHEESE_ARRAY) ; 


在 这 种 习惯 用 法 中 ， 零 长 度数 组 常量 被 传递 给 toArray 方 法 ， 以 指明 所 期 望 的 返回 类 型 。 
正常 情况 下 ，toArray 方 法 分 配 了 返回 的 数组 ， 但 是 ， 如 果 集 合 是 空 的 ， 它 将 使 用 零 长 度 的 输 
人 数组 ，Collection.toArray(TU) 的 规范 保证 : 如 果 输 入 数组 大 到 足够 容纳 这 个 集合 ， 它 就 将 
返回 这 个 输入 数组 。 因 此 ， 这 种 做 法 永远 也 不 会 分 配 零 长 度 的 数组 。 


同样 地 ， 集 合 值 的 方法 也 可 以 做 成 在 每 当 和 需要 返回 空 集合 时 都 返回 同一 个 不 可 变 的 空 集 
合 。Collections.emptySet、emptyList 和 emptyMap 方 法 提供 的 正 是 你 所 需要 的 ， 如 下 所 示 : 


// The right way to return a copy of a collection 
public List<Cheese> getCheeseList() { 
if (cheesesInStock. isEmpty()) 
return Collections.emptyList(); // Always returns same list 
else 
return new ArrayList<Cheese>(cheesesInStock); 


} 


简 而 言 之 ， 返 回 类 型 为 数组 或 集合 的 方法 没 理由 返回 null， 而 不 是 返回 一 个 零 长 度 的 数组 
或 者 集合 。 这 种 习惯 做 法 〈 指 返回 null) 很 有 可 能 是 从 C 程 序 设计 语言 中 治 袭 过 来 的 ， 在 C 语 
言 中 ， 数 组 长 度 是 与 实际 的 数组 分 开 返 回 的 。 在 C 语 言 中 ， 如 果 返 回 的 数组 长 度 为 零 ， 再 分 配 
一 个 数组 就 没有 任何 好 处 。 
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SREEGIA PE Miura 


如 果 要 想 使 一 个 API 真 正 可 用 ， 就 必须 为 其 编写 文档 。 传 统 意义 上 的 API 文 档 是 手工 生成 
的 ， 所 以 保持 文档 与 代码 同步 是 一 件 很 繁琐 的 事情 。Java 语 言 环境 提供 了 一 种 被 称 为 Javadoc 
的 实用 工具 ， 从 而 使 这 项 任务 变 得 很 容易 。Javadoc 利 用 特殊 格式 的 文档 注释 (documentation 
comment, 通常 被 写作 doc comment) ， 根 据 源 代 码 自 动产 生 API 文 档 。 


如 果 你 对 文档 注释 的 规范 还 不 太 熟 悉 ， 应 该 去 了 解 这些 规 范 。 虽 然 这 些 规范 还 没有 正式 成 
为 Java 程 序 设计 语言 的 一 部 分 ， 但 它们 已 经 构成 了 每 个 程序 员 都 应 该 知道 的 事实 API。 这 些 规 
范 的 内 容 在 Sun 公 司 关 于 如 何 编写 文档 注释 (How to Write Doc Comments) 的 网 页 上 进行 
了 说 明 [Javadoc-guide]。 虽 然 这 个 网 页 在 Java 1.4 发 行 版 本 之 后 还 没有 进行 更 新 ， 但 它 仍然 是 
个 很 有 价值 的 资源 。Java 1.5 发 行 版 本 中 ， 为 Javadoc 新 增 了 两 个 重要 的 Javadoc 标 签 : 
{@literal} 和 {@code}[Javadoc-5.0]。 本 条 目 中 会 讨论 到 这 些 标签 。 


为 了 正确 地 编写 API 文 档 ， 必 须 在 每 个 被 导出 的 类 、 接 口 、 构 造 器 、 方 法 和 域 声 明之 前 增 
加 一 个 文档 注释 。 如 果 类 是 可 序列 化 的 ， 也 应 该 对 它 的 序列 化 形式 编写 文档 ( 见 第 75 条 )。 如 
果 没 有 文档 注释 ，Javadoc 所 能 够 做 的 也 就 是 重新 生成 该 声明 ， 作 为 受 影响 的 API 元 素 的 唯一 
文档 。 使 用 没有 文档 注释 的 API 是 非常 痛苦 的 ， 也 很 容易 出 错 。 为 了 编写 出 可 维护 的 代码 ， 还 
应 该 为 那些 没有 被 导出 的 类 、 接 口 、 构 造 器 、 方 法 和 域 编写 文档 注释 。 


方法 的 文档 注释 应 该 简洁 地 描述 出 它 和 客户 端 之 间 的 约定 。 除 了 专门 为 继承 而 设计 的 类 中 
的 方法 ( 见 第 17 条 ) 之 外 ， 这 个 约定 应 该 说 明 这 个 方法 做 了 什么 ， 而 不 是 说 明 它 是 如 何 完成 这 
项 工作 的 。 文 档 注释 应 该 列举 出 这 个 方法 的 所 有 前 提 条 件 (precondition) 和 后 置 条 件 
(postcondition) ， 所 谓 前 提 条 件 是 指 为 了 使 客户 能 够 调用 这 个 方法 ， 而 必须 要 满足 的 条 件 ， 所 
谓 后 置 条 件 是 指 在 调用 成 功 完 成 之 后 ， 哪 些 条 件 必 须要 满足 。 一 般 情况 下 ， 前 提 条 件 是 由 
@throws 标 签 针对 未 受 检 的 异常 所 隐 含 描述 的 ， 每 个 未 受 检 的 异常 都 对 应 一 个 前 提 违 例 
(precondition violation) 。 同 样 地 ， 也 可 以 在 一 些 受 影响 的 参数 的 @param 标 记 中 指定 前 提 条 件 。 


除了 前 提 条 件 和 后 置 条 件 之 外 ， 每 个 方法 还 应 该 在 文档 中 描述 它 的 副作用 (side effect), 
所 谓 副作用 是 指 系统 状态 中 可 以 观察 到 的 变化 ， 它 不 是 为 了 获得 后 置 条 件 而 明确 要 求 的 变化 。 
例如 ， 如 果 方 法 启动 了 后 台 线 程 ， 文 档 中 就 应 该 说 明 这 一 点 。 最 后 ， 文 档 注释 也 应 该 描述 类 
或 者 方法 的 线程 安全 性 (thread safety) ， 正 如 第 70 条 中 所 述 。 


为 了 完整 地 描述 方法 的 约定 ， 方 法 的 文档 注释 应 该 让 每 个 参数 都 有 一 个 @param 标 签 ， 以 
及 一 个 @return 标 签 (除非 这 个 方法 的 返回 类 型 为 void) ， 以 及 对 于 该 方法 抛 出 的 每 个 异常 ， 无 
论 是 受 检 的 还 是 未 受 检 的 ， 都 有 一 个 @throws 标 签 ( 见 第 62 条 ) 。 按 惯例 ， 跟 在 @param 标 签 
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或 者 @return 标 签 后 面 的 文字 应 该 是 一 个 名 词 短 语 ， 描 述 了 这 个 参数 或 者 返回 值 所 表示 的 值 。 
跟 在 @throws 标 签 之 后 的 文字 应 该 包含 单词 “if”( 如 果 )， 紧 接着 是 一 个 名 词 短语 ， 它 描述 了 
这 个 异常 将 在 什么 样 的 条 件 下 会 被 抛 出 。 有 时 候 ， 也 会 用 算术 表达 式 来 代替 名 词 短 语 。 按 惯 
例 ，@param、@return 或 者 @throws 标 签 后 面 的 短语 或 者 子 句 都 不 用 句点 来 结束 。 下 面 这 个 简 
短 的 文档 注释 演示 了 所 有 这 些 习惯 做 法 : 


[we 

* Returns the element at the specified position in this list. 
* 

+ <p>This method is <i>not</i> guaranteed to run in constant 

+ time. In some implementations it may run in time proportional 
* to the element position. 

* 

+ @param index index of element to return; must be 

* non-negative and less than the size of this list 

* @return the element at the specified position in this list 

* @throws IndexOutOfBoundsException if the index is out of range 

({@code index < 0 || index >= this.size()}) 


xy/ 
E get(int index); 


注意 ， 这 份 文档 注释 中 使 用 了 HTML 标 签 (<p> 和 <i>)。Javadoc 工 具 会 把 文档 注释 翻译 成 
HTML， 文 档 注释 中 包含 的 任意 HTML 元 素 都 会 出 现在 结果 HTML 文 档 中 。 有 时 候 ， 程 序 员 会 
把 HTML 表 格 嵌 入 到 它们 的 文档 注释 中 ， 但 是 这 种 做 法 并 不 多 见 


还 要 注意 ，@throws 子 句 的 代码 片段 中 到 处 使 用 了 Javadoc 的 {@code} 标 签 。 它 有 两 个 作 
FA: 造成 该 代码 片段 以 代码 字体 (code font) 进行 呈现 ， 并 限制 HTML 标 记 和 艇 套 的 Javadoc 
标签 在 代码 片段 中 进行 处 理 。 后 一 种 属性 正 是 允许 我 们 在 代码 片段 中 使 用 小 于 号 (<) 的 东西 ， 
虽然 它 是 一 个 HTML 元 字符 。 在 Java 1.5 发 行 版 本 之 前 ， 是 通过 使 用 HTML 标 签 和 HTML 转 义 ， 
将 代码 片段 包含 在 文档 注释 中 。 现 在 再 也 没有 必要 在 文档 注释 中 使 用 HTML <code> 或 者 <tt> 
标签 了 : Javadoc {@code} 标 签 更 好 ， 因 为 它 避 免 了 转 义 HTML 元 字符 。 为 了 将 多 个 代码 示例 
包含 在 一 个 文档 注释 中 ， 要 使 用 包 在 HTML 的 <pre> 标 签 里 面 的 Javadoc {@code} 标 签 。 换 句 
话说 ， 是 先 在 多 行 的 代码 示例 前 使 用 字符 <pre>{f@code， 然 后 在 代码 后 面 加 上 }</pre>。 


最 后 ， 要 注意 这 个 文档 注释 中 用 到 了 单词 “this”。 按 惯例 ， 当 “this” 被 用 在 实例 方法 的 
文档 注释 中 时 ， 它 应 该 始终 是 指 方法 调用 所 在 的 对 象 。 


不 要 忘记 ,为 了 产生 包含 HTML 元 字符 的 文档 ， 比 如 小 于 号 (<)、 大 于 号 (>) 以 及 “与 ” 
号 (&&)， 必 须 采 取 特 殊 的 动作 。 让 这 些 字符 出 现在 文档 中 的 最 佳 办 法 是 用 {@literal} 标 签 将 它 
们 包围 起 来 ， 这 样 就 限制 了 HTML 标 记 和 徐 套 的 Javadoc 标 签 的 处 理 。 除 了 它 不 以 代码 字体 得 
染 文本 之 外 ， 其 余 方 面 就 像 {@code} 标 签 一 样 。 例 如 ， 这 个 Javadoc 片 段 : 


+ The triangle inequality is {@literal |x + y| < |x] + lyl}. 
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产生 了 这 样 的 文档 : “The triangle inequality is Ix + yl < Ixl + lyl.”{@literal} 标 签 也 可 以 
只 是 包 住 小 于 号 ， 而 不 是 整个 不 等 式 ， 所 产生 的 文档 是 一 样 的 ， 但 是 在 源 代码 中 见 到 的 文档 
注释 的 可 读 性 就 会 更 差 。 这 说 明了 一 条 通则 : 文档 注释 在 源 代 码 和 产生 的 文档 中 都 应 该 是 易 
于 阅读 的 。 如 果 无 法 让 两 者 都 易 读 ， 产生 的 文档 的 可 读 性 要 优先 于 源 代 码 的 可 读 性 。 


每 个 文档 注释 的 第 一 句 话 (如 下 所 示 ) 成 了 该 注释 所 属 元 素 的 概要 描述 (summary 
description)。 例 如 ， 第 177 页 中 文档 注释 中 的 概要 描述 为 “返回 这 个 列表 中 指定 位 置 上 的 元 
素 "。 概 要 描述 必须 独立 地 描述 目标 元 素 的 功能 。 为 了 避免 混 消 ， 同 一 个 类 或 者 接口 中 的 两 个 
成 员 或 者 构造 器 ， 不 应 该 具有 同样 的 概要 描述 。 特别 要 注意 重 载 的 情形 ， 在 这 种 情况 下 ， 往 
往 很 自然 地 在 描述 中 使 用 同样 的 第 一 句 话 (但 在 文档 注释 中 这 是 不 可 接受 的 )。 


注意 所 期 待 的 概要 描述 中 是 否 包括 句点 ， 因 为 句点 会 过 早 地 终止 这 个 描述 。 例 如 ， 一 个 以 
“A college degree, such as B.S., M.S., or Ph.D.” 开 头 的 文档 注释 ， 会 产生 这 样 的 概要 描述 : 
“A college degree, such as.B.S，M.S.” 问 题 在 于 ， 概 要 描述 在 后 面 接着 空格 、 跳 格 或 者 行 终 
结 符 的 第 一 个 句点 处 (或 者 在 第 一 个 块 标签 处 ) 结束 [Javadoc-refl] 。 在 这 种 情况 下 ， 缩 写 
“M.S.” 中 的 第 二 个 句点 就 要 接着 用 一 个 空格 。 最 好 的 解决 方法 是 ， 将 讨厌 的 句点 以 及 任何 与 
{@literal} 关 联 的 文本 都 包 起 来 ， 因 此 在 源 代码 中 ， 句 点 后 面 就 不 再 是 空格 了 : 

har college degree, such as B.S., {@literal M.S.} or Ph.D. 

* College is a fountain of knowledge where many go to drink. 


*/ 
public class Degree { ... } 


说 概要 描述 是 文档 注释 中 的 第 一 个 句子 (sentence) ， 这 似乎 有 点 误导 人 。 规 范 指出 ， 概 
要 描述 很 少 是 个 完整 的 句子 。 对 于 方法 和 构造 器 而 言 ， 概 要 描述 应 该 是 个 完整 的 动词 短语 
(包含 任何 对 象 ) ， 它 描述 了 该 方法 所 执行 的 动作 。 例 如 : 


° ArrayList(int initialCapacity) 一 Constructs an empty list with the specified initial 


capacity. (用 指定 的 初始 容量 构造 一 个 空 的 列表 ) 


。 Collection.size()—Returns the number of elements in this collection. (返回 该 集合 中 元 


素 的 数目 ) 


对 于 类 、 接 口 和 域 ， 概 要 描述 应 该 是 一 个 名 词 短 语 ， 它 描述 了 该 类 或 者 接口 的 实例 ， 或 者 
域 本 身 所 代表 的 事物 。 例 如 : 


e TimerTask—A task that can be scheduled for one-time or repeated execution by a Timer. 


(可 以 调度 一 次 的 任务 ， 或 者 被 Timer 重 复 执行 的 任务 ) 


Bate 179 


¢ Math.PI—The double value that is closer than any other to pi, the ratio of the 


circumference of a circle to its diameter. (非常 接近 于 PI (圆周 长 度 与 直径 的 比值 ) 的 
double 值 ) 


Java 1.5 发 行 版 本 中 增加 的 三 个 特性 在 文档 注释 中 需要 特别 小 心 : 泛 型 、 枚 举 和 注解 。 当 
为 泛 型 或 者 方法 编写 文档 时 ， 确 保 要 在 文档 中 说 明 所 有 的 类 型 参数 。 


An object that maps keys to values. A map cannot contain 
duplicate keys; each key can map to at most one value. 


(Remainder omitted) 


+ @param <K> the type of keys maintained by this map 
+ @param <V> the type of mapped values 
*/ 
public interface Map<K, V> { 
... // Remainder omitted 
} 


当 为 枚 举 类 型 编写 文档 时 ， 要 确保 在 文档 中 说 明 常 量 ， 以 及 类 型 ， 还 有 任何 公有 的 方法 。 
注意 ， 如 果 文 档 注释 很 简短 ， 可 以 将 整个 注释 放 在 一 行 上 : 


[we 
* An instrument section of a symphony orchestra. 
*/ 
public enum OrchestraSection { 
/** Woodwinds, such as flute, clarinet, and oboe. «/ 
WOODWIND , 


/sw Brass instruments, such as french horn and trumpet. «/ 
BRASS, 


/x* Percussion instruments, such as timpani and cymbals «/ 
PERCUSSION, 


/ss Stringed instruments, such as violin and cello. «/ 
STRING; 
} 


为 注解 类 型 编写 文档 时 ， 要 确保 在 文档 中 说 明 所 有 成 员 ， 以 及 类 型 本 身 。 带 有 名 词 短 语 的 
文档 成 员 ， 就 像 是 域 一 样 。 对 于 该 类 型 的 概要 描述 ， 要 使 用 一 个 动词 短语 ， 说 明 当 程 序 元 素 
具有 这 种 类 型 的 注解 时 它 表 示 什 么 意思 。 


[we 
* Indicates that the annotated method is a test method that 
* must throw the designated exception to succeed. 


* 
/ 
@Retention(RetentionPolicy.RUNTIME) 
@Target (ElementType.METHOD) 
public @interface ExceptionTest { 
[ee 
* The exception that the annotated test method must throw 
* in order to pass. (The test is permitted to throw any 
+ subtype of the type described by this class object.) 


*/ 
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Class<? extends Exception> value(); 


从 Java 1.5 发 行 版 本 开始 ， 包 级 私有 的 文档 注释 就 应 该 放 在 一 个 称 作 package-info.java 的 
文件 中 ， 而 不 是 放 在 package.html 中 。 除 了 包 级 私有 的 文档 注释 之 外 ，package-info.java 也 可 
以 (但 并 非 必需 ) 包含 包 声 明和 包 注 解 。 


类 的 导出 API 有 两 个 特征 经 常 被 人 忽视 ， 即 线程 安全 性 和 可 序列 化 性 。 类 是 否 是 线程 安全 
的 ， 应 该 在 文档 中 对 它 的 线程 安全 级 别 进行 说 明 ， 如 第 70 条 中 所 述 。 如 果 类 是 可 序列 化 的 ， 
就 应 该 在 文档 中 说 明 它 的 序列 化 形式 ， 如 第 75 条 中 所 述 。 


Javadoc 具 有 “继承 ”方法 注释 的 能 力 。 如 果 API 元 素 没 有 文档 注释 ，Javadoc 将 会 搜索 最 
为 适用 的 文档 注释 ， 接 口 的 文档 注释 优先 于 超 类 的 文档 注释 。 搜 索 算法 的 细节 可 以 在 《The 
Javadoc Reference Guide》[Javadoc-ref] 中 找到 。 也 可 以 利用 {@inheritDoc} 标 签 从 超 类 型 中 
继承 文档 注释 的 部 分 内 容 。 这 意味 着 ， 不 说 别 的 ， 类 还 可 以 重用 它 所 实现 的 接口 的 文档 注释 ， 
而 不 需要 拷贝 这 些 注释 。 这 项 机 制 有 可 能 减轻 维护 多 个 几乎 相同 的 文档 注释 的 负担 ， 但 它 使 
用 起 来 比较 需要 一 些小 技巧 (tricky)， 并 具有 一 些 局 限 性 。 关 于 这 一 点 的 详情 超出 了 本 书 的 
范围 ， 在 此 不 做 讨论 。 


为 了 降低 文档 注释 中 出 错 的 可 能 性 ， 一 种 简单 的 办 法 是 通过 一 个 HTML 有 效 性 检查 器 
(HTML validity checker) 来 运行 由 Javadoc 产 生 的 HTML 文 件 。 这 样 可 以 检测 出 HTML 标签 
的 许多 不 正确 用 法 ， 以 及 应 该 被 转 义 的 HTML 元 字符 。Internet 上 有 一 些 HTML 有 效 性 检查 器 
可 供 下 载 ， 并 且 可 以 在 线 检验 HTML[W3C-validator]。 : 


关于 文档 注释 有 一 点 需要 特别 注意 。 虽 然 为 所 有 导出 的 API 元 素 提 供 文档 注释 是 必要 的 ， 
但 是 这 样 做 并 非 永 远 就 足够 了 。 对 于 由 多 个 相互 关联 的 类 组 成 的 复杂 API， 通 常 有 必要 用 一 个 
外 部 文档 来 描述 该 API 的 总 体 结 构 ， 对 文档 注释 进行 补充 。 如 果 有 这 样 的 文档 ， 相 关 的 类 或 者 
包 文 档 注释 就 应 该 包含 一 个 对 这 个 外 部 文档 的 链接 。 


本 条 目 中 所 述 的 内 容 涵 盖 了 基本 的 惯例 。 关 于 编写 文档 注解 最 权威 的 指导 是 Sun 公 司 的 
«How to Write Doc Comments (如 何 编写 文档 注释 )》[Javadoc-guide]。 


简 而 言 之 ， 要 为 API 编 写 文档 ， 文 档 注释 是 最 好 、 最 有 效 的 途径 。 对 于 所 有 可 导出 的 API 
元 素来 说 ， 使 用 文档 注释 应 该 被 看 作 是 强制 性 的 。 要 采用 一 致 的 风格 来 遵循 标准 的 约定 。 记 
住 ， 在 文档 注释 内 部 出 现任 何 HTML 标 签 都 是 允许 的 ， 但 是 HTML 元 字符 必须 要 经 过 转 义 。 





第 8 章 
通用 程序 设计 
本 章 主 要 讨论 Java 语 言 的 具体 细节 ， 讨 论 了 局 部 变量 的 处 理 、 控 制 结构 ， 类 库 的 用 法 ， 


各 种 数据 类 型 的 用 法 ， 以 及 两 种 不 是 由 语言 本 身 提供 的 机 制 (reflection 和 native method ， 反 
射 机 制 和 本 地 方法 ) 的 用 法 。 最 后 讨论 了 优化 和 命名 惯例 。 





本 条 目 与 第 13 条 (使 类 和 成 员 的 可 访问 性 最 小 化 ) 本 质 上 是 类 似 的 。 将 局 部 变量 的 作用 
域 最 小 化 ， 可 以 增强 代码 的 可 读 性 和 可 维护 性 ， 并 降低 出 错 的 可 能 性 。 


较 早 的 程序 设计 语言 (如 C 语 言 ) 要 求 局 部 变量 必须 在 一 个 代码 块 的 开头 处 进行 声明 ， 出 
于 习惯 ， 有 些 程序 员 们 目前 还 是 继续 这 样 做 。 这 个 习惯 应 该 改正 。 在 此 提醒 ，Java 人 允许 你 在 任 
何 可 以 出 现 语句 的 地 方 声明 变量 。 


要 使 局 部 变量 的 作用 域 最 小 化 ， 最 有 力 的 方法 就 是 在 第 一 次 使 用 它 的 地 方 声明 。 如 果 变 量 
在 使 用 之 前 进行 声明 ， 这 只 会 造成 混乱 一 一 对 于 试图 理解 程序 功能 的 读者 来 说 ， 这 又 多 了 一 种 
只 会 分 散 他 们 注意 力 的 因素 。 等 到 用 到 该 变量 的 时 候 ， 读 者 可 能 已 经 记 不 起 该 变量 的 类 型 或 
者 初始 值 了 。 


过 早 地 声明 局 部 变量 不 仅 会 使 它 的 作用 域 过 早 地 扩展 ， 而 且 结 束 得 也 过 于 晚 了 。 局 部 变量 
的 作用 域 从 它 被 声明 的 点 开始 扩展 ， 一 直到 外 围 块 (block) 的 结束 处 。 如 果 变 量 是 在 “使 用 
它 的 块 ”之 外 被 声明 的 ， 当 程序 退出 该 块 之 后 ， 该 变量 仍 是 可 见 的 。 如 果 变 量 在 它 的 目标 使 
用 区 域 之 前 或 者 之 后 被 意外 地 使 用 的 话 ， 后 果 将 可 能 是 灾难 性 的 。 


几乎 每 个 局 部 变量 的 声明 都 应 该 包含 一 个 初始 化 表达 式 。 如 果 你 还 没有 足够 的 信息 来 对 一 
个 变量 进行 有 意义 的 初始 化 ， 就 应 该 推迟 这 个 声明 ， 直 到 可 以 初始 化 为 止 。 这 条 规则 有 个 例 
外 的 情况 与 try-catch 语 句 有 关 。 如 果 一 个 变量 被 一 个 方法 初始 化 ， 而 这 个 方法 可 能 会 抛 出 一 个 
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受 检 的 异常 (checked exception) ， 该 变量 就 必须 在 try 块 的 内 部 被 初始 化 。 如 果 变 量 的 值 必须 
在 try 块 的 外 部 被 使 用 到 ， 它 就 必须 在 try 块 之 前 被 声明 ， 但 是 在 try 块 之 前 ， 它 还 不 能 被 “有 意 
义 地 初始 化 ”。 请 参照 第 202 页 中 的 例子 。 


循环 中 提供 了 特殊 的 机 会 来 将 变量 的 作用 域 最 小 化 。( 无 论 是 传统 的 还 是 for-each 形 式 的 ) 
for 循 环 ， 都 允许 声明 循环 变量 (loop variable) ， 它 们 的 作用 域 被 限定 在 正好 需要 的 范围 之 内 。 
(这 个 范围 包括 循环 体 ， 以 及 循环 体 之 前 的 初始 化 、 测 试 、 更 新 部 分 。) 因此 ， 如 果 在 循环 终 
止 之 后 不 再 需要 循环 变量 的 内 容 ，for 循 环 就 优先 于 while 循 环 。 


例如 ， 下 面 是 一 种 遍历 集合 的 首选 做 法 ( 见 第 46 条 ): 


// Preferred idiom for iterating over a collection 
for (Element e : c) { 

doSomething(e) ; 
} 


在 Java 1.5 发 行 版 本 之 前 ， 首 选 的 做 法 如 下 (现在 仍然 有 适用 之 处 ): 


// No for-each loop or generics before release 1.5 

for (Iterator i = c.iterator(); i.hasNext(); ) { 
doSomething((Element) i.next()); 

} 


为 了 和 弄 清楚 为 什么 这 个 for 循 环比 while 循 环 更 好 ， 请 考虑 下 面 的 代码 片断 ， 它 包含 两 个 
while 循 环 ， 以 及 一 个 Bug : 
Iterator<Element> i = c.iterator(); 


while (i.hasNextQ)) { 
doSomething(i.next(Q)); 


Iterator<Element> i2 = c2.iterator(); 

while (i.hasNextQ)) { // BUG! 

; doSomethingElse(i2.next()); 

第 二 个 循环 中 包含 一 个 “ 剪 切 -粘贴 ”错误 : 它 本 来 是 要 初始 化 一 个 新 的 循环 变量 i2， 却 
使 用 了 旧 的 循环 变量 1， 遗憾 的 是 ， 这 时 i 仍然 还 在 有 效 范 围 之 内 。 结 果 代 码 仍然 可 以 通过 编译 ， 
运行 的 时 候 也 不 会 抛 出 异常 ， 但 是 它 所 做 的 事情 却 是 错误 的 。 第 二 个 循环 并 没有 在 c2 上 过 代 ， 
而 是 立即 终止 ， 造 成 c2 为 空 的 假象 。 因 为 这 个 程序 的 错误 是 悄然 发 生 的 ， 所 以 可 能 在 很 长 时 
间 内 都 不 会 被 发 现 。 


” 如果 类 似 的 “ 剪 切 -粘贴 ”错误 发 生 在 前 面 任何 一 种 for 循 环 中 ， 结 果 代 码 就 根本 不 能 通过 
编译 。 在 第 二 个 循环 开始 之 前 ， 第 一 个 循环 的 元 素 (或 者 迭代 器 ) 变量 已 经 不 在 它 的 作用 域 
范围 之 内 了 : 
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for (Iterator<Element> i = c.iterator(); i.hasNextQ); ) { 
doSomething(i.next()); 
} 


// Compile-time error - cannot find symbol i 

for (Iterator<Element> i2 = c2.iterator(); i.hasNextQ); ) { 
doSomething(i2.next()); 

} 


而 且 ， 如 果 使 用 for 循 环 ， 犯 这 种 “ 剪 切 -粘贴 ”错误 的 可 能 性 就 会 大 大 降低 ， 因 为 通常 没 
有 必要 在 两 个 循环 中 使 用 不 同 的 变量 名 。 循 环 是 完全 独立 的 ， 所 以 重用 元 素 (或 者 迭代 器 ) 
变量 的 名 称 不 会 有 任何 危害 。 实 际 上 , ,这 也 是 很 流行 的 做 法 。 


使 用 for 循 环 与 使 用 while 循 环 相 比 还 有 另外 一 个 优势 : 更 简短 ， 从 而 增强 了 可 读 性 。 
下 面 是 另外 一 种 对 局 部 变量 的 作用 域 进行 最 小 化 的 循环 做 法 : 


for (int i = 0, n = expensiveComputation(); i < n; i++) { 
doSomething(i); 
} 


关于 这 种 做 法 要 关注 的 一 点 是 , 它 具 有 两 个 循环 变量 : i 和 n， 两 者 具有 完全 相同 的 作用 域 。 
第 二 个 变量 n 被 用 来 保存 第 一 个 变量 的 极限 值 ， 从 而 避免 在 每 次 迭代 中 执行 元 余 计 算 的 开销 。 
通常 ， 如 果 循 环 测试 中 涉及 方法 调用 ， 它 可 以 保证 在 每 次 迭代 中 都 会 返回 同样 的 结果 ， 就 应 
该 使 用 这 种 做 法 。 


最 后 一 种 “将 局 部 变量 的 作用 域 最 小 化 ”的 方法 是 使 方法 小 而 集中 。 如 果 把 两 个 操作 
(activity) 合并 到 同一 个 方法 中 ， 与 其 中 一 个 操作 相关 的 局 部 变量 就 有 可 能 会 出 现在 执行 另 一 
个 操作 的 代码 范围 之 内 。 为 了 防止 这 种 情况 发 生 ， 只 要 把 这 个 方法 分 成 两 个 ， 每 个 方法 各 执 
行 一 个 操作 。 
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在 Java 1.5 发 行 版 本 之 前 ， 对 集合 进行 遍历 的 首选 做 法 如 下 : 


// No longer the preferred idiom to iterate over a collection! 
for (Iterator i = c.iterator(); i.hasNext(); ) { 

doSomething((Element) i.next()); // (No generics before 1.5) 
} 


遍历 数组 的 首选 做 法 如 下 : 


// No longer the preferred idiom to iterate over an array! 
for Cint i = 0; i < a.length; i++) { 

doSomething(a[i]); 
} 


这 些 做 法 都 比 while 循 环 〈 见 第 45 条 ) 更 好 ， 但 是 它们 也 并 不 完美 。 迭代 器 和 索引 变量 都 
会 造成 一 些 混乱 。 而 且 ， 它 们 也 代表 着 出 错 的 可 能 。 和 迭代 器 和 索引 变量 在 每 个 循环 中 出 现 三 
次 ， 其 中 有 两 次 让 你 很 容易 出 错 。 一 旦 出 错 ， 就 无 法 保证 编译 器 能 够 发 现 错误 。 


Java 1.5 发 行 版 本 中 引入 的 for-each 循 环 ， 通 过 完全 隐藏 迭 代 器 或 者 索引 变量 ， 和 避免 了 混 
乱 和 出 错 的 可 能 。 这 种 模式 同样 适用 于 集合 和 数组 : 
// The pdt idiom for iterating over collections and arrays 


for (Element e : elements) { 
doSomething(e); 
} 


当 见 到 冒号 (:) 时 ， 可 以 把 它 读 作 “ 在 … 里 面 "。 因 此 上 面 的 循环 可 以 读 作 “对 于 元 素 
中 的 每 个 元 素 e。” 注 意 ， 利 用 for-each 循 环 不 会 有 性 能 损失 ， 甚 至 用 于 数组 也 一 样 。 实 际 上 ， 
在 某 些 情况 下 ， 比 起 普通 的 for 循 环 ， 它 还 稍 有 些 性 能 优势 ， 因 为 它 对 数组 索引 的 边界 值 只 计 
算 一 次 。 虽 然 可 以 手工 完成 这 项 工作 ( 见 第 45 条 ) ， 但 程序 员 并 不 总 会 这 么 做 。 


在 对 多 个 集合 进行 嵌 套 式 迭 代 时 ，for-each 循 环 相 对 于 传统 for 循 环 的 这 种 优势 还 会 更 加 明 
显 。 下 面 就 是 人 们 在 试图 对 两 个 集合 进行 从 套色 代 时 经 常会 犯 的 错误 : 


// Can you spot the bug? 

enum Suit { CLUB, DIAMOND, HEART, SPADE } 

enum Rank { ACE, DEUCE, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, 
NINE, TEN, JACK, QUEEN, KING } 


Collection<Suit> suits = Arrays.asList(Suit.values()); 
Collection<Rank> ranks = Arrays.asList(Rank.values()); 


List<Card> deck = new ArrayList<Card>(); 
for (Iterator<Suit> i = suits.iterator(); i.hasNext(Q); ) 
for (Iterator<Rank> j = ranks.iteratorQ); j.hasNext(); ) 
deck.add(new Card(i.next(), j.nextQ)); 
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如 果 之 前 没有 发 现 这 个 Bug 也 不 必 难 过 。 许 多 专家 级 的 程序 员 偶尔 也 会 犯 这 样 的 错误 。 问 
BEF, EKRE ERIB RA (suits) 调用 了 太 多 次 next 方 法 了 。 它 应 该 从 外 部 的 循环 进 
行 调用 ， 以 便 每 种 花色 调用 一 次 ,但 它 却 是 从 内 部 循环 调用 ， 因 此 它 是 每 张 牌 调用 一 次 。 在 
用 完 所 有 花色 之 后 ， 循 环 就 会 抛 出 NoSuchElementException 异 常 。 


如 果真 的 那么 不 幸 ， 并 且 外 部 集合 的 大 小 是 内 部 集合 大 小 的 儿 倍 一 一 可 能 因为 它们 是 相同 
的 集合 一 一 循环 就 会 正常 终止 , 但 是 不 会 完成 你 想 要 的 工作 。 例如， 下 面 是 个 考虑 不 周 的 尝试 ， 
要 打印 一 对 骨 子 的 所 有 可 能 的 滚 法 。 

ape TONE, THO, TREE. FOUR, FIVE, SIX } 

Collection<Face> faces = Arrays.asList(Face.values()); 

for (Iterator<Face> i = faces.iterator(); i.hasNext(); ) 


for (Iterator<Face> j = faces.iterator(); j.hasNext(); ) 
System.out.printin(i.next(Q) + " " + j.nextQ)); 


这 个 程序 不 会 抛 出 异常 ， 而 是 只 打印 6 个 重复 的 词 (从 “ONE ONE” ¥ “SIX SIX”), 而 
不 是 预计 的 36 种 组 合 。 


为 了 修正 这 些 示 例 中 的 Bug， 必 须 在 外 部 循环 的 作用 域 中 添加 一 个 变量 来 保存 外 部 元 素 : 


// Fixed, but ugly - you can do better! 
for (Iterator<Suit> i = suits.iterator(); i.hasNext(); ) { 
Suit suit = i.next(); 
for (Iterator<Rank> j = ranks.iterator(); j.hasNext(); ) 
deck.add(new Card(suit, j.next())); 
} 
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// Preferred idiom for nested iteration on collections and arrays 

for (Suit suit : suits) 


for (Rank rank : ranks) 
deck.add(new Card(suit, rank)); 


for-each 循 环 不 仅 让 你 遍历 集合 和 数组 ， 还 让 你 遍历 任何 实现 Iterable 接 口 的 对 象 。 这 个 简单 
的 接口 由 单个 方法 组 成 ， 与 for-each 循 环 同时 被 增加 到 Java 平 台中 。 下 面 就 是 这 个 接口 的 示例 : 
public interface Iterable<E> { 


// Returns an iterator over the elements in this iterable 
Iterator<E> iterator(); 


实现 Iterable 接 口 并 不 难 。 如 果 你 在 编写 的 类 型 表示 的 是 一 组 元 素 ， 即 使 你 选择 不 让 它 实 
现 Collection， 也 要 让 它 实 现 Iterable。 这 样 可 以 允许 用 户 利用 for-each 循 环 遍历 你 的 类 型 ， 会 
令 用 户 永远 感激 不 尽 的 。 
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总 之 ，for-each 循 环 在 简洁 性 和 预防 Bug 方 面 有 着 传统 的 for 循 环 无 法 比拟 的 优势 ， 并 且 没 
有 性 能 损失 。 应 该 尽 可 能 地 使 用 for-each 循 环 。 遗 憾 的 是 ， 有 三 种 常见 的 情况 无 法 使 用 for- 
each 循 环 : 


1. 过 滤 一 一 如 果 需 要 遍历 集合 ， 并 删除 选 定 的 元 素 ， 就 需要 使 用 显 式 的 友 代 器 ， 以 便 可 以 
调用 它 的 remove 方 法 。 


2. 转换 一 一 如 果 需 要 遍历 列表 或 者 数组 ， 并 取代 它 部 分 或 者 全 部 的 元 素 值 ， 就 需要 列表 过 
代 器 或 者 数组 索引 ， 以 便 设 定 元 素 的 值 。 


3. 平行 迭代 一 一 如 果 需 要 并 行 地 遍历 多 个 集合 ， 就 需要 显 式 地 控制 迭代 器 或 者 索引 变量 ， 
以 便 所 有 迭代 器 或 者 索引 变量 都 可 以 得 到 同步 前 移 (就 如 上 述 关 于 有 问题 的 牌 和 山子 
的 示例 中 无 意 中 所 示范 的 那样 ) 。 


在 以 上 任何 一 种 情况 下 ， 就 要 使 用 普通 的 for 循 环 ， 要 警惕 本 条 目 中 提 到 的 陷阱 ， 并 且 要 
确保 做 到 最 好 。 
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假设 你 希望 产生 位 于 0 和 某 个 上 界 之 间 的 随机 整数 。 面 对 这 个 常见 的 任务 ， 许 多 程序 员 会 
编写 出 如 下 所 示 的 方法 : 


private static final Random rnd = new Random(); 
// Common but deeply flawed! 


static int random(int n) { 
return Math.abs(rnd.nextInt()) % n; 


这 个 方法 看 起 来 可 能 不 错 ， 但 是 却 有 三 个 缺点 。 第 一 个 缺点 是 ， 如 果 n 是 一 个 比较 小 的 2 
”的 乘 方 ， 经 过 一 段 相当 短 的 周期 之 后 ， 它 产生 的 随机 数 序列 将 会 重复 。 第 二 个 缺点 是 ， 如 果 n 
不 是 2 的 乘 方 ， 那 么 平均 起 来 ， 有 些 数 会 比 其 他 的 数 出 现 得 更 为 频繁 。 如 果 n 比 较 大 ， 这 个 缺 
点 就 会 非常 明显 。 这 可 以 通过 下 面 的 程序 直观 地 体现 出 来 ， 它 会 产生 一 百 万 个 经 过 细心 指定 
的 范围 内 的 随机 数 ， 并 打印 出 有 多 少 个 数字 落 在 随机 数 取 值 范围 的 前 半 部 分 : 


public static void main(String[] args) { 
int n = 2 * (Integer.MAX_VALUE / 3); 
int low = 0; 
for Cint i = 0; i < 1000000; i++) 
if Crandom(n) < n/2) 
low++; 


System.out.printin(low) ; 


如 果 random 方 法 工作 正常 的 话 ， 这 个 程序 打印 出 来 的 数 将 接近 于 一 百 万 的 一 半 ， 但 是 如 
果真 正 运行 这 个 程序 ， 就 会 发 现 它 打印 出 来 的 数 接近 于 666 666。 由 random 方 法 ) 生 的 数字 有 
2/3 落 在 随机 数 取 值 范围 的 前 半 部 分 。 


random 方 法 的 第 三 个 缺点 是 ， 在 极 少数 情况 下 ， 它 的 失败 是 灾难 性 的 ， 返 回 一 个 落 在 指 
定 范围 之 外 的 数 。 之 所 以 如 此 ， 是 因为 这 个 方法 试图 通过 调用 Math.abs， 将 rnd.nextInt() 返 回 
的 值 映射 为 一 个 非 负 整数 int。 如 果 nextInt() 返 回 Integer.MIN_VALUE， 那 么 Math.abs 也 会 返 
ElInteger.MIN_VALUE, 假设 n 不 是 2 的 乘 方 ， 那 么 取 模 操作 符 (%) 将 返回 一 个 负数 。 这 几 
乎 肯定 会 使 程序 失败 ， 而 且 这 种 失败 很 难 重 现 。 


为 了 编写 能 修正 这 三 个 缺点 的 random 方 法 ， 有 必要 了 解 关于 伪 随 机 数 生成 器 、 数 论 和 2 的 
求 补 算法 的 相关 知识 。 幸 运 的 是 ， 你 并 不 需要 自己 来 做 这 些 工作 一 一 已 经 有 现成 的 成 果 可 以 为 
你 所 用 。 它 被 称 为 Random.nextInt(int)， 自 Java 1.2 发 行 版 本 以 来 ， 它 已 经 成 了 Java 平 台 的 一 
部 分 。 


你 无 需 关 心 nextInt(inb 的 实现 细节 (如 果 你 有 强烈 的 好 奇 心 ， 可 以 研究 它 的 文档 或 者 源 代 
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码 )。 具 有 算法 背景 的 高 级 工程 师 已 经 花 了 大 量 的 时 间 来 设计 、 实 现 和 测试 这 个 方法 ， 然 后 经 ~ 
过 这 个 领域 中 的 专家 的 审查 ， 以 确保 它 的 正确 性 。 然 后 ， 标 准 类 库 经 过 了 Beta 测 试 、 发 行 和 
近 十 年 的 成 千 上 万 程序 员 的 广泛 使 用 。 在 这 个 方法 中 还 没有 发 现 过 人 缺陷， 但是， 如 果 将 来 发 
现 有 缺陷 ， 在 下 一 个 发 行 版 本 中 就 会 修正 这 些 缺 陷 。 通 过 使 用 标准 类 库 ， 可 以 充分 利用 这 些 
编写 标准 类 库 的 专家 的 知识 ， 以 及 在 你 之 前 的 其 他 人 的 使 用 经 验 。 


使 用 标准 类 库 的 第 二 个 好 处 是 ， 不 必 浪 费时 间 为 那些 与 工作 不 太 相关 的 问题 提供 特别 的 解 
决 方案 。 就 像 大 多 数 程序 员 一 样 ， 应 该 把 时 间 花 在 应 用 程序 上 ， 而 不 是 底层 的 细节 上 。 


使 用 标准 类 库 的 第 三 个 好 处 是 ， 它 们 的 性 能 往往 会 随 着 时 间 的 推移 而 不 断 提高 ， 无 需 你 做 
任何 努力 。 因 为 许多 人 在 使 用 它们 ， 被 当 作 工业 标准 在 使 用 ， 所 以 ， 提 供 这 些 标 准 类 库 的 组 
织 有 强烈 的 动机 要 使 它们 运行 得 更 快 。 这 些 年 来 ， 许 多 Java 平 台 类 库 已 经 被 重新 编写 了 ， 有 时 
候 是 重复 编写 ， 从 而 导致 性 能 上 有 了 显著 的 提高 。 


标准 类 库 也 会 随 着 时 间 的 推移 而 增加 新 的 功能 。 如 果 类 库 中 漏 掉 了 某 些 功能 ， 开 发 者 社区 
(developer community) 就 会 把 这 些 缺 点 告示 出 来 , 漏 掉 的 功能 就 会 添加 到 后 续 的 发 行 版 本 中 。 
Java 平 台 类 库 始终 是 在 这 个 社区 的 推动 下 不 断 发 展 的 。 


.使 用 标准 类 库 的 最 后 一 个 好 处 是 ， 可 以 使 自己 的 代码 融入 主流 。 这 样 的 代码 更 易 读 、 更 易 
维护 、 更 易 被 大 多 数 的 开发 人 员 重 用 。 


既然 有 那么 多 的 优点 ， 使 用 标准 类 库 机 制 而 不 选择 专门 的 实现 ， 这 显然 是 符合 逻辑 的 ， 然 
而 还 是 有 相当 一 部 分 的 程序 员 没 有 这 样 做 。 为 什么 呢 ? 可 能 他 们 并 不 知道 有 这 些 类 库 机 制 的 
存在 。 在 每 个 重要 的 发 行 版 本 中 ， 都 会 有 许多 新 的 特性 被 加 入 到 类 库 中 ， 所 以 与 这 些 新 特性 
保持 同步 是 值得 的 。 每 次 Java 平 台 有 重要 的 发 行 时 ，Sun 公 司 都 会 发 布 一 个 网 页 ， 说 明 新 的 特 
性 。 这 些 网 页 值得 好 好 读 一 读 [Java5-feat，Java6-feat]。 这 些 标准 类 库 太 庞大 了 ， 以 至 于 不 可 
能 去 学 习 所 有 的 文档 [JavaSE6]， 但 是 每 个 程序 员 都 应 该 熟 色 java.lang、java.util， 某 种 程度 
上 还 有 java.io 中 的 内 容 。 关 于 其 他 类 库 的 知识 可 以 根据 需要 随时 学 习 。 


本 条 目 不 可 能 总 结 类 库 中 所 有 的 便利 工具 ， 但 是 有 两 种 工具 值得 特别 一 提 。 在 1.2 发 行 版 
本 中 ，Collections Framework (集合 框架 ) 被 加 入 到 了 java.util 包 中 。 它 应 该 成 为 每 个 程序 
员 基 本 工具 箱 中 的 一 部 分 。Collections Framework 是 一 个 统一 的 体系 结构 ， 用 来 表示 和 操作 
集合 ,允许 它们 对 集合 进行 独立 于 表示 细节 的 操作 。 它 减轻 了 编程 的 负担 , 同时 还 提升 了 性 能 。 
它 考 虑 到 不 相关 的 API 之 间 的 互 操作 性 ， 减 少 了 为 设计 和 学 习 新 的 API 所 要 付出 的 努力 ， 并 且 
鼓励 软件 重用 。 如 果 想 要 了 解 更 多 这 方面 的 细节 ， 请 参见 Sun 公 司 网 站 上 的 文章 [Collections]， 
或 者 阅读 有 关 的 教程 [Bloch06]。 


1.5 发 行 版 本 中 ， 在 java.util.concurrent 包 中 增加 了 一 组 并 发 实用 工具 。 这 个 包 既 包含 高 
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级 的 并 发 工具 来 简化 多 线程 的 编程 任务 ， 还 包含 低级 别 的 并 发 基本 类 型 ， 允 许 专家 们 自己 编 
写 更 高 级 的 并 发 抽象 。java.util.concurrent 的 高 级 部 分 ， 也 应 该 是 每 个 程序 员 基 本 工具 箱 中 的 
一 部 分 ( 见 第 68 条 和 第 69 条 )。 


在 有 些 情况 下 ， 一 个 类 库 工具 并 不 能 满足 你 的 需要 。 你 的 需求 越 是 特殊 ， 这 种 情形 就 越 有 
可 能 发 生 。 虽 然 你 的 第 一 个 念头 应 该 是 使 用 标准 类 库 ， 但 是 ， 如 果 你 在 观察 了 它们 在 某 些 领 
域 所 提供 的 功能 之 后 ， 确 定 它 不 能 满足 需要 ， 你 就 得 使 用 其 他 的 实现 。 任 何 一 组 类 库 所 提供 
的 功能 总 是 难免 会 有 遗漏 。 如 果 你 所 需要 的 功能 不 存在 ， 那 么 ， 就 只 能 自己 实现 这 些 功能 ， 
别 无 选择 。 


总 而 言 之 ， 不 要 重新 发 明 轮 子 。 如 果 你 要 做 的 事情 看 起 来 是 十 分 常见 的 ， 有 可 能 类 库 中 已 
经 有 某 个 类 完成 了 这 样 的 工作 。 如 果 确 实 是 这 样 ， 就 使 用 现成 的 ， 如 果 还 不 清楚 是 否 存在 这 
样 的 类 ， 就 去 查 一 查 。 一 般 而 言 ， 类 库 的 代码 可 能 比 你 自己 编写 的 代码 更 好 二 些 ， 并 且 会 随 
着 时 间 的 推移 而 不 断 改进 。 这 并 不 是 在 影射 你 作为 一 个 程序 员 的 能 力 。 从 经 济 角 度 的 分 析 表 
明 : 类 库 代 码 受到 的 关注 远 远 超过 大 多 数 普通 程序 员 在 同样 的 功能 上 所 能 够 给 予 的 投入 。 





float 和 double 类 型 主要 是 为 了 科学 计算 和 工程 计算 而 设计 的 。 它 们 执行 二 进 制 浮 点 运算 
(binary floating-point arithmetic) ， 这 是 为 了 在 广泛 的 数值 范围 上 提供 较为 精确 的 快速 近似 
计算 而 精心 设计 的 。 然 而 ， 它 们 并 没有 提供 完全 精确 的 结果 ， 所 以 不 应 该 被 用 于 需要 精确 结 
果 的 场合 。float 和 double 类 型 尤其 不 造 合用 于 货币 计算 ， 因 为 要 让 一 个 float 或 者 double 精 确 
地 表示 0.1 (或 者 10 的 任何 其 他 负数 次 方 值 ) 是 不 可 能 的 。 


例如 ， 假 设 你 的 口袋 中 有 $1.03， 花 掉 了 42¢ 之 后 还 剩 下 多 少 钱 呢 ”下面 是 一 个 很 简单 的 程 
序 片断 ， 要 回答 这 个 问题 : 


System.out ,println(1.03 - .42); 


遗憾 的 是 ， 它 输出 的 结果 是 0.6100000000000001。 这 并 不 是 个 别 的 例子 。 假 设 你 的 口袋 
里 有 $1， 你 买 了 9 个 垫圈 ， 每 个 为 10¢。 那 么 你 应 该 找 回 多 少 零头 呢 ? 


System.out.println(1.00 - 9 * .10); 
根据 这 个 程序 片断 ， 你 得 到 的 是 $0.09999999999999998 。 


你 可 能 会 认为 ， 只 要 在 打印 之 前 将 结果 做 一 下 伟人 就 可 以 解决 这 个 问题 ， 但 遗憾 的 是 ， 这 
种 做 法 并 不 总 是 可 行 。 例 如 ， 假 设 你 的 口袋 里 有 $1， 你 看 到 货架 上 有 一 排 美味 的 糖果 ， 标 价 
分 别 为 10¢、20¢、30¢， 等 等 ,一 直到 $1。 你 打算 从 标价 为 10¢ 的 糖果 开始 ， 每 种 买 1 颗 ， 一 直 
到 不 能 支付 货架 上 下 一 种 价格 的 糖果 为 止 ， 那 么 你 可 以 买 多 少 颗 糖果 ? SE 
下 面 是 一 个 简单 的 程序 ， 用 来 解决 这 个 问题 : 


// Broken - uses floating point for monetary calculation! 
public static void main(String[] args) { 
double funds = 1.00; 
int itemsBought = 0; 
for (double price = .10; funds >= price; price += .10) { 
funds -= price; 
jtemsBought++; 


System.out.printInCitemsBought + " items bought."); 
A System.out.printin("Change: $" + funds); 
如 果真 正 运行 这 个 程序 ,你 会 发 现 你 可 以 支付 3 颗 糖 果 , 并 且 还 剩 下 $0.3999999999999999。 
这 个 答案 是 不 正确 的 ! 解决 这 个 问题 的 正确 办 法 是 使 用 BigDecimal、int 或 者 long 进 行货 币 
计算 。 


下 面 的 程序 是 上 一 个 程序 的 简单 翻版 ， 它 使 用 BigDecimal 类 型 代替 double， 


下 
public static void main(String[] args) { 
final BigDecimal TEN_CENTS = new BigDecimal( ".10"); 
int itemsBought = 0; 
BigDecimal funds = new BigDecimal("1.00"); 
for (BigDecimal price = TEN_CENTS; 
funds.compareTo(price) >= 0; 
price = price.add(TEN_CENTS)) { 
jtemsBought++; 
funds = funds.subtract(price); 


System.out.printin(itemsBought + " items bought."); 
System.out.printin("Money left over: $" + funds); 
} 


如 果 运 行 这 个 修改 过 的 程序 ， 就 会 发 现 你 可 以 支付 4 颗 糖 果 ， 还 剩 下 $0.00。 这 才 是 正确 的 
答案 。 


然而 ， 使 用 BigDecimal 有 两 个 缺点 : 与 使 用 基本 运算 类 型 相 比 ， 这 样 做 很 不 方便 ， 而 且 
很 慢 。 对 于 解决 这 样 一 个 简单 的 问题 ， 后 一 种 缺点 并 不 要 紧 ， 但 是 前 一 种 缺点 可 能 会 让 你 很 
不 舒服 。 


除了 使 用 BigDecimal 之 外 ， 还 有 一 种 办 法 是 使 用 int 或 者 long， 到 底 选 用 int 或 者 long 要 取 
决 于 所 涉及 数值 的 大 小 ， 同 时 要 自己 处 理 十 进 制 小 数 点 。 在 这 个 示例 中 ， 最 明显 的 做 法 是 以 
分 为 单位 进行 计算 ， 而 不 是 以 元 为 单位 。 下 面 是 这 个 例子 的 简单 翻版 ， 展 示 了 这 种 做 法 ， 

public static void main(String[] args) { 

int itemsBought = Q; 
int funds = 100; 
for (int price = 10; funds >= price; price += 10) { 
jtemsBought++; 
funds -= price; 
RR + " items bought."); 
System.out.printla("Money left over: "+ funds + " cents"); 


} 


总 而 言 之 ， 对 于 任何 需要 精确 答案 的 计算 任务 ， 请 不 要 使 用 float 或 者 double。 如 果 你 想 让 
系统 来 记录 十 进 制 小 数 点 ， 并 且 不 介意 因为 不 使 用 基本 类 型 而 带 来 的 不 便 ， 就 请 使 用 
BigDecimal。 使 用 BigDecimal 还 有 一 些 额外 的 好 处 ， 它 允许 你 完全 控制 伟人 ， 每 当 一 个 操作 
涉及 舍 入 的 时 候 ， 它 允许 你 从 8 种 舍 入 模式 中 选择 其 一 。 如 果 你 正 通过 法 定 要 求 的 舍 和 信行 为 进 
行业 务 计算 ,使 用 BigDecimal 是 非常 方便 的 。 如 果 性 能 非常 关键 ， 并 且 你 又 不 介意 自己 记录 
十 进 制 小 数 点 ， 而 且 所 涉及 的 数值 又 不 太 大 ， 就 可 以 使 用 int 或 者 long。 如 果 数 值 范围 没有 超 
过 9 位 十 进 制 数字 ， 就 可 以 使 用 int， 如 果 不 超 过 18 位 数字 ， 就 可 以 使 用 long。 如 果 数 值 可 能 超 
过 18 位 数字 ， 就 必须 使 用 BigDecimal。 
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Java 有 一 个 类 型 系统 由 两 部 分 组 成 ,包含 基本 类 型 (primitive) ， 如 int、double 和 boolean， 
和 引用 类 型 (reference type), ， 如 String 和 List。 每 个 基本 类 型 都 有 一 个 对 应 的 引用 类 型 ， 称 
作 装 箱 基 本 类 型 (boxed primitive) 。 装 箱 基 本 类 型 中 对 应 于 int、double 和 boolean 的 是 
Integer、Double 和 Boolean。 


Java 1.5 发 行 版 本 中 增加 了 自动 装 箱 (autoboxing) 和 自动 拆 箱 (auto-unboxing) 。 如 第 
5 条 所 述 ， 这 些 特性 模糊 了 但 并 没有 完全 抹 去 基本 类 型 和 装 箱 基 本 类 型 之 间 的 区 别 。 这 两 种 类 
型 之 间 真 正 是 有 差别 的 ， 要 很 清楚 在 使 用 的 是 哪 种 类 型 ， 并 且 要 对 这 两 种 类 型 进行 谨慎 的 选 
择 ， 这 些 都 非常 重要 。 


在 基本 类 型 和 装 箱 基本 类 型 之 间 有 三 个 主要 区 别 。 第 一 ， 基 本 类 型 只 有 值 ， 而 装 箱 基 本 类 
型 则 具有 与 它们 的 值 不 同 的 同一 性 。 换 句 话说， 两 个 装 箱 基 本 类 型 可 以 具有 相同 的 值 和 不 同 
的 同一 性 。 第 二 ， 基 本 类 型 只 有 功能 完备 的 值 ， 而 每 个 装 箱 基 本 类 型 除了 它 对 应 基本 类 型 的 
所 有 功能 值 之 外 ， 还 有 个 非 功能 值 : null。 最 后 一 点 区 别 是 ， 基 本 类 型 通常 比 装 箱 基 本 类 型 更 
节省 时 间 和 空间 。 如 果 不 小 心 ， 这 三 点 区 别 都 会 让 你 陷入 麻烦 之 中 。 


考虑 下 面 这 个 比较 器 ， 它 被 设计 用 来 表示 Integer 值 的 递增 数字 顺序 。( 回 想 一 下 ， 比 较 器 
的 compare 方 法 返回 的 数值 到 底 为 负数 、 零 还 是 正 数 ， 要 取决 于 它 的 第 一 个 参数 是 小 于 、 等 于 
还 是 大 于 它 的 第 二 个 参数 。) 在 实践 中 并 不 需要 你 编写 这 个 在 Integer 中 实现 自然 顺序 的 比较 器 ， 
因为 这 是 不 需要 比较 器 就 可 以 得 到 的 ， 但 它 展 示 了 一 个 值得 关注 的 例子 : 

// Broken comparator - can you spot the flaw? 

Comparator<Integer> naturalOrder = new Comparator<Integer>() { 

public int compare(Integer first, Integer second) { 


return first < second ? -1 : (first == second ? 0 : 1); 


}; 


这 个 比较 器 表面 看 起 来 似乎 不 错 ， 它 可 以 通过 许多 测试 。 例 如 ， 它 可 以 通过 Collections,sort 
正确 地 给 一 个 有 一 百 万 个 元 素 的 列表 进行 排序 ， 无 论 这 个 列表 中 是 否 包含 重复 的 元 素 。 但 是 这 
个 比较 器 有 着 严重 的 缺陷 。 如 果 你 要 让 自己 信服 ， 只 要 打印 naturalOrder.Compare(new 
Integer(42) 和 new Integer(42)) 的 值 。 这 两 个 Integer 实 例 都 表示 相同 的 值 (42)， 因 此 这 个 表达 式 的 
值 应 该 为 0， 但 它 输 出 的 却 是 1， 这 表明 第 一 个 Integer 值 大 于 第 二 个 。 


问题 出 在 哪 呢 ? naturalOrder 中 的 第 一 个 测试 工作 得 很 好 。 对 表达 式 first < second 执 行 计 
算 会 导致 被 first 和 second 引 用 的 Integer 实 例 被 自动 拆 箱 (auto-unboxed) ， 也 就 是 说 ， 它 提 
取 了 它们 的 基本 类 型 值 。 计 算 动作 要 检查 产生 的 第 一 个 int 值 是 否 小 于 第 二 个 。 但 是 假设 答案 
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是 否定 的 。 下 一 个 测试 就 是 执行 计算 表达 式 first == second， 它 在 两 个 对 象 引 用 上 执行 同一 性 
比较 (identity comparison)., 如 果 first 和 second 引 用 表示 同一 个 int 值 的 不 同 的 Integer 实 例 ， 
这 个 比较 操作 就 会 返回 false， 比 较 器 会 错误 地 返回 1， 表 示 第 一 个 Integer 值 大 于 第 二 个 。 对 装 
箱 基本 类 型 运用 == 操 作 符 几乎 总 是 错误 的 。 


修正 这 个 问题 最 清楚 的 做 法 是 添加 两 个 局 部 变量 ， 来 保存 对 应 于 first 和 second 的 基本 类 型 
int 值 ， 并 在 这 些 变量 上 执行 所 有 的 比较 操作 。 这 样 可 以 避免 大 量 的 同一 性 比较 ， 
Comparator<Integer> naturalOrder = new Comparator<Integer>() { 
public int compare(Integer first, Integer second) { 
int f = first; // Auto-unboxing 
int s = second; // Auto unboxing 
return f < s ? -1 : (f ==s ? 0 : 1); // No unboxing 


3; 


接 下 来 ， 考 虑 这 个 小 程序 : 


public class Unbelievable { 
static Integer i; 


public static void main(String[{] args) { 
* if (i == 42) 
System.out.printIn("Unbelievable"); 


} 


它 不 是 打印 出 Unbelievable 一 一 但 是 它 的 行为 也 是 很 奇怪 的 。 它 在 计算 表达 式 (i == 42) 
的 时 候 抛 出 NullPointerException 异 常 。 问 题 在 于 ， i 是 个 Integer， 而 不 是 int， 就 像 所 有 的 对 象 
引用 域 一 样 ， 它 的 初始 值 为 null。 当 程序 计算 表达 式 (i == 42) 时 ， 它 会 将 Integer 与 int 进 行 比较 。 
几乎 在 任何 一 种 情况 下 ， 当 在 一 项 操作 中 混合 使 用 基本 类 型 和 装 糊 基本 类 型 时 ， 装 箱 基 本 类 
型 就 会 自动 拆 箱 ， 这 种 情况 无 一 例外 。 如 果 null 对 象 引 用 被 自动 拆 箱 ， 就 会 得 到 一 个 
NullPointerException 异 常 。 就 如 这 个 程序 所 示 ， 它 几乎 可 以 在 任何 位 置 发 生 。 修正 这 个 问题 
很 简单 ， 声 明 i 是 个 int 而 不 是 Integer 就 可 以 了 。 


最 后 ， 考 虑 第 5 条 中 的 这 个 程序 : 


// Hideously slow program! Can you spot the object creation? 
public static void main(String[] args) { 
Long sum = @L; 
for (long i = 0; i < Integer.MAX_VALUE; i++) { 
sum += i; 


System.out.printIn(sum); 


这 个 程序 运行 起 来 比 预计 的 要 慢 一 些 ， 因 为 它 不 小 心 将 一 个 局 部 变量 (sum) 声明 为 是 装 
箱 基本 类 型 Long ， 而 不 是 基本 类 型 long。 程 序 编译 起 来 没有 错误 或 者 警告 ， 变量 被 反复 地 装 
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箱 和 拆 箱 ， 导 致 明显 的 性 能 下 降 。 


在 本 条 目 中 所 讨论 的 这 三 个 程序 中 ， 问 题 是 一 样 的 : 程序 员 忽 略 了 基本 类 型 和 装 箱 基 本 类 
型 之 间 的 区 别 ， 并 尝 到 了 苦头 。 在 前 两 个 程序 中 ， 其 结果 是 彻底 的 失败 ， 在 第 三 个 程序 中 ， 
则 有 严重 的 性 能 问题 。 


那么 什么 时 候 应 该 使 用 装 箱 基本 类 型 呢 ? 它们 有 几 个 合理 的 用 处 。 第 一 个 是 作为 集合 中 的 
元 素 、 键 和 值 。 你 不 能 将 基本 类 型 放 在 集合 中 ， 因 此 必须 使 用 装 箱 基本 类 型 。 这 是 一 种 更 通 
用 的 特例 。 在 参数 化 类 型 ( 见 第 5 章 ) 中 ， 必 须 使 用 装 箱 基 本 类 型 作为 类 型 参数 ， 因 为 Java 不 
允许 使 用 基本 类 型 。 例 如 ， 你 不 能 将 变量 声明 为 ThreadLocal<int> 类 型 ， 因 此 必须 使 用 
ThreadLocal<Integer> 代 替 。 最 后 ， 在 进行 反射 的 方法 调用 ( 见 第 53 条 ) 时 ， 必 须 使 用 装 箱 基 
本 类 型 。 


总 之 ， 当 可 以 选择 的 时 候 ， 基 本 类 型 要 优先 于 装 箱 基本 类 型 。 基 本 类 型 更 加 简单 ， 也 更 加 
快速 。 如 果 必 须 使 用 装 箱 基本 类 型 ， 要 特别 小 心 ! 自动 装 箱 减 少 了 使 用 装 箱 基 本 类 型 的 繁琐 
性 ， 但 是 并 没有 减少 它 的 风险 。 当 程序 用 == 操 作 符 比较 两 个 装 箱 基本 类 型 时 ， 它 做 了 个 同一 
性 比较 ， 这 几乎 肯定 不 是 你 所 希望 的 。 当 程序 进行 涉及 装 箱 和 拆 箱 基本 类 型 的 混合 类 型 计算 
时 ， 它 会 进行 拆 箱 ， 当 程序 进行 拆 箱 时 ， 会 抛 出 NullPointerException 异 常 。 最 后 ， 当 程序 装 
箱 了 基本 类 型 值 时 ， 会 导致 高 开销 和 不 必要 的 对 象 创建 。 
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字符 串 被 用 来 表示 文本 ， 它 在 这 方面 也 确实 做 得 很 好 。 因 为 字符 串 很 通用 ， 并 且 Java 语 言 
也 支持 得 很 好 ， 所 以 自然 就 会 有 这 样 一 种 倾向 : 即使 在 不 适合 使 用 字符 串 的 场合 ， 人 们 往往 
也 会 使 用 字符 串 。 本 条 目 就 是 讨论 一 些 不 应 该 使 用 字符 串 的 情形 。 


字符 串 不 适合 代替 其 他 的 值 类 型 。 当 一 段 数据 从 文件 、 网 络 ， 或 者 键盘 设备 ， 进 入 到 程序 
中 之 后 ， 它 通常 以 字符 串 的 形式 存在 。 有 一 种 自然 的 倾向 是 让 它 继续 保留 这 种 形式 ， 但 是 ， 
只 有 当 这 段 数据 本 质 上 确实 是 文本 信息 时 ， 这 种 想法 才 是 合理 的 。 如 果 它 是 数值 ， 就 应 该 被 
转换 为 适当 的 数值 类 型 ， 比 如 int、float 或 者 BigInteger 类 型 。 如 果 它 是 一 个 “是 一 或 一 否 ” 这 
种 问题 的 答案 ， 就 应 该 被 转换 为 boolean 类 型 。 如 果 存 在 适当 的 值 类 型 ， 不 管 是 基本 类 型 ， 还 
是 对 象 引 用 ， 大 多 应 该 使 用 这 种 类 型 ， 如 果 不 存 在 这 样 的 类 型 ， 就 应 该 编写 一 个 类 型 。 虽 然 
这 条 建议 是 显而易见 的 ， 但 却 经 常 遭 到 违反 。 


字符 串 不 适合 代替 枚 举 类 型 。 正 如 第 30 条 中 所 讨论 的 ， 枚 举 类 型 比 字符 串 更 加 适合 用 来 
表示 枚 举 类 型 的 常量 。 


字符 串 不 适合 代替 聚集 类 型 。 如 果 一 个 实体 有 多 个 组 件 ， 用 一 个 字符 串 来 表示 这 个 实体 通 
常 是 很 不 恰当 的 。 例 如 ， 下 面 这 行 代码 来 自 于 真实 的 系统 一 一 标识 符 的 名 称 已 经 被 修改 了 ， 以 
免 发 生 纠 纷 : 

// Inappropriate use of string as aggregate type 

String compoundKey = className + "#" + i.next(); 

这 种 方法 有 许多 缺点 。 如 果 用 来 分 隔 域 的 字符 也 出 现在 某 个 域 中 ， 结 果 就 会 出 现 混乱 。 为 
了 访问 单独 的 域 ， 必 须 解 析 该 字符 串 ， 这 个 过 程 非常 慢 ， 也 很 繁琐 ， 还 容易 出 错 。 你 无 法 提 
供 equals、toString 或 者 compareTo 方 法 ， 只 好 被 迫 接受 String 提 供 的 行为 。 更 好 的 做 法 是 ， 简 
单 地 编写 一 个 类 来 描述 这 个 数据 集 ， 通 常 是 一 个 私有 的 静态 成 员 类 ( 见 第 22 条 )。 


字符 串 也 不 适合 代替 能 力 表 (capabilities)。 有 了 时候 ， 字 符 串 被 用 于 对 某 种 功能 进行 授 
权 访 问 。 例 如 ， 考 虑 设计 一 个 提供 线程 局 部 变量 (thread-local variable) 的 机 制 。 这 个 机 制 提 
供 的 变量 在 每 个 线程 中 都 有 自己 的 值 。 自 从 Java 1.2 发 行 版 本 以 来 ，Java 类 库 就 有 提供 线程 局 
部 变量 的 机 制 ， 但 在 那 之 前 ， 程 序 员 必 须 自己 完成 。 几 年 前 面 对 这 样 的 设计 任务 时 ， 有 些 人 
自己 提出 了 同样 的 设计 方案 : 利用 客户 提供 的 字符 串 键 ， 对 每 个 线程 局 部 变量 的 内 容 进 行 访 
问 授权 : 

// Broken - inappropriate use of string as capability! 


public class ThreadLocal 
private ThreadLocal() { } // Noninstantiable 
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// Sets the current thread's value for the named variable. 
public static void set(String key, Object value); 


// Returns the current thread's value for the named variable. 


public static Object get(String key); 
} 


这 种 方法 的 问题 在 于 , 这 些 字符 串 键 代 表 了 一 个 共享 的 全 局 命名 空间 。 要 使 这 种 方法 可 行 ， 
客户 端 提供 的 字符 串 键 必须 是 唯一 的 : 如 果 两 个 客户 端 各 自决 定 为 它们 的 线程 局 部 变量 使 用 
同样 的 名 称 ， 它 们 实际 上 就 无 意 中 共享 了 这 个 变量 ， 这 样 往往 会 导致 两 个 客户 端 都 失败 。 而 
且 ， 安 全 性 也 很 差 。 恶 意 的 客户 端 可 能 有 意 地 使 用 与 另 一 个 客户 端 相 同 的 键 ， 以 便 非 法 地 访 
问 其 他 客户 端的 数据 。 - 


要 修正 这 个 API 并 不 难 ， 只 要 用 一 个 不 可 伪造 的 键 (unforgeable key， 有 时 被 称 为 能 力 
(capability) ) 来 代替 字符 串 即 可 : 
public class ThreadLocal { 
private Threadlocal() { } // Noninstantiable 
public static class Key { // (Capability) 
Key() { } 


// Generates a unique, unforgeable key 
public static Key getKey( { 
return new Key(); 


public static void set(Key key, Object value); 
public static Object get(Key key); 
} 
虽然 这 解决 了 基于 字符 串 的 API 的 两 个 问题 ， 但 是 你 还 可 以 做 得 更 好 。 你 实际 上 不 再 需要 
静态 方法 ， 它 们 可 以 被 代 之 以 键 (Key) 中 的 实例 方法 ， 这 样 这 个 键 就 不 再 是 键 ， 而 是 线程 局 
部 变量 了 。 此 时 ， 这 个 不 可 被 实例 化 的 顶层 类 也 不 再 做 任何 实质 性 的 工作 ， 因 此 可 以 删除 这 
个 顶层 类 ， 并 将 内 层 的 藤 套 类 命名 为 ThreadLocal: 
public final class ThreadLocal { 
public ThreadLocal() { } 


public void set(Object value); 
public Object get(); 


这 个 API 不 是 类 型 安全 的 ， 因 为 当 你 从 线程 局 部 变量 得 到 它 时 ， 必 须 将 值 从 Object 转换 成 
它 实际 的 值 。 不 可 能 使 原始 的 基于 String 的 API 为 类 型 安全 的 ， 要 使 基于 Key 的 API 为 类 型 安全 
的 也 很 困难 ， 但 是 ， 通 过 将 ThreadLocal 类 泛 型 化 ( 见 第 26 条 )， 使 这 个 API 变 成 类 型 安全 的 就 
是 很 简单 的 事情 了 : 


public final class ThreadLocal<T> { 





通用 程序 设计 = 
public ThreadLocalQ) { } 


public void set(T value); 
public T getQ); 


粗略 地 讲 ， 这 正 是 java.util.ThreadLoc 纪 提供 的 API。 除 了 解决 了 基于 字符 串 的 API 的 问题 
之 外 ， 与 前 面 的 两 个 基于 键 的 API 相 比 ， 它 还 更 快速 、 更 优雅 。 


总 而 言 之 ， 如 果 可 以 使 用 更 加 合适 的 数据 类 型 ， 或 者 可 以 编写 更 加 适当 的 数据 类 型 ， 就 应 
该 避免 用 字符 串 来 表示 对 象 。 若 使 用 不 当 ， 字 符 串 会 比 其 他 的 类 型 更 加 笨拙 、 更 不 灵活 、 速 
度 更 慢 ， 也 更 容易 出 错 。 经 常 被 错误 地 用 字符 串 来 代替 的 类 型 包括 基本 类 型 、 枚 举 类 型 和 聚 
集 类 型 。 
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字符 串 连 接 操 作 符 (+, string concatenation operator) 是 把 多 个 字符 串 合 并 为 一 个 字符 串 
的 便利 途径 。 要 想 产生 单独 一 行 的 输出 ， 或 者 构造 一 个 字符 串 来 表示 一 个 较 小 的 、 大 小 固定 
的 对 象 ， 使 用 连接 操作 符 是 非常 合适 的 ， 但 是 它 不 适合 运用 在 大 规模 的 场景 中 。 为 连接 mn 个 字 
符 事 而 重复 地 使 用 字符 囊 连 接 操 作 符 ， 需 要 n 的 平方 级 的 时 间 。 这 是 由 于 字符 串 不 可 变 ( 见 第 
ISA) 而 导致 的 不 幸 结果 。 当 两 个 字符 串 被 连接 在 一 起 时 ， 它 们 的 内 容 都 要 被 拷贝 。 


例如 ,考虑 下 面 的 方法 , 它 通过 反复 连接 每 个 项 目 行 , 构造 出 一 个 代表 该 对 账单 的 字符 串 。 
代码 如 下 : 


// Inappropriate use of string concatenation - Performs horribly! 
public String statement() { 
String result = "" 
for Cint i = 0; i < numItems(); i++) 
result += lineForItem(i); // String concatenation 
return result; 


如 果 项 目 数量 巨大 ， 这 个 方法 的 执行 时 间 就 难以 估算 。 为 了 获得 可 以 接受 的 性 能 ， 请 使 用 
StringBuilder 替 代 String， 来 存储 建造 中 的 对 账单 。(Java 1.5 发 行 版 本 中 增加 了 非 同步 
StringBuilder 类 ， 代 替 了 现在 已 经 过 时 的 StringBuffer 类 。) ; 


public String statement() { 
StringBuilder b = new StringBui lder(numItems() + LINE_WIDTH) ; 
for (int i = 0; i < numItemsQ); i++) 
b.append(lineForItem(i)); 
return b.toString(Q); 


上 述 两 种 做 法 的 性 能 差别 非常 大 。 如 果 numItems 返 回 100， 并 且 lineForItem 返 回 一 个 固定 
长 度 为 80 个 字符 的 字符 串 ， 在 我 的 机 器 上 ， 第 二 种 做 法 比 第 一 种 做 法 要 快 85 倍 。 因 为 第 一 种 
做 法 的 开销 随 项 目 数量 而 呈 平 方 级 增加 ， 第 二 种 做 法 则 是 线性 增加 ， 所 以 ,项 目 数 越 大 ， 性 
能 的 差别 会 越 显著 。 注意， 第 二 种 做 法 预先 分 配 了 一 个 StringBuilder， 使 它 大 到 足以 容纳 结果 
字符 串 。 即 使 因为 预先 不 知道 字符 串 长 度 ， 使 用 了 默认 大 小 的 StringBuilder， 它 仍 然 比 第 一 种 
做 法 快 50 倍 。， 


原则 很 简单 : 不 要 使 用 字符 串 连 接 操作 符 来 合并 多 个 字符 串 ， 除非 性 能 无 关 紧要 。 相反 ， 
应 该 使 用 StringBuilder 的 append 方 法 。 另 一 种 方法 是 ， 使 用 字符 数组 ， 或 者 每 次 只 处 理 一 个 字 
符 串 ， 而 不 是 将 它们 组 合 起 来 。 
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第 40 条 中 有 一 个 建议 : 应 该 使 用 接口 而 不 是 用 类 作为 参数 的 类 型 。 更 一 般 地 讲 ， 应 该 优 
先 使 用 接口 而 不 是 类 来 引用 对 象 。 如 果 有 合适 的 接口 类 型 存在 ， 那 么 对 于 参数 、 返 回 值 、 变 
量 和 域 来 说 ， 就 都 应 该 使 用 接口 类 型 进行 声明 。 只 有 当 你 利用 构造 器 创建 某 个 对 象 的 时 候 ， 
才 真 正 需 要 引用 这 个 对 象 的 类 。 为 了 更 具体 地 说 明 这 一 点 ， 我 们 来 考虑 Vector 的 情形 ， 它 是 
List 接 口 的 一 个 实现 。 在 声明 变量 的 时 候 应 该 养 成 这 样 的 习惯 : 


// Good - uses interface as type 
List<Subscriber> subscribers = new Vector<Subscriber>(); 


而 不 是 像 这 样 的 声明 : 


// Bad - uses class as type! , 
Vector<Subscriber> subscribers = new Vector<Subscriber>(); 


如 果 你 养 成 了 用 接口 作为 类 型 的 习惯 ， 你 的 程序 将 会 更 加 灵活 。 当 你 决定 更 换 实现 时 ， 所 
要 做 的 就 只 是 改变 构造 器 中 类 的 名 称 (或 者 使 用 一 个 不 同 的 静态 工厂 ) 。 例 如 ， 第 一 个 声明 可 
以 被 改变 为 : | 


List<Subscriber> subscribers = new ArrayList<Subscriber>(); 


周围 的 所 有 代码 都 可 以 继续 工作 。 周 围 的 代码 并 不 知道 原来 的 实现 类 型 ， 所 以 它们 对 于 这 
种 变化 并 不 在 意 。 


有 一 点 值得 注意 : 如 果 原 来 的 实现 提供 了 某 种 特殊 的 功能 ， 而 这 种 功能 并 不 是 这 个 接口 的 
通用 约定 所 要 求 的 ， 并 且 周 围 的 代码 又 依赖 于 这 种 功能 ， 那 么 很 关键 的 一 点 是 ， 新 的 实现 也 
要 提供 同样 的 功能 。 例 如 ， 如 果 第 一 个 声明 周围 的 代码 依赖 于 Vector 的 同步 策略 ， 在 声明 中 用 
ArrayList 代 替 Vector 就 是 不 正确 的 。 如 果 依 赖 于 实现 的 任何 特殊 属性 ， 就 要 在 声明 变量 的 地 
方 给 这 些 需 求 建立 相应 的 文档 说 明 。 


那么 ， 为 什么 要 改变 实现 呢 ? 因为 新 的 实现 提供 了 更 好 的 性 能 ， 或 者 因为 它 提供 了 期 望 得 
到 的 额外 功能 。 有 个 真实 的 例子 与 ThreadLocal 类 有 关 。 在 内 部 ， 这 个 类 在 Thread 中 使 用 了 一 
个 包 级 私有 的 Map 域 ， 将 每 个 线程 的 值 (per-thread values) 与 ThreadLocal 实 例 关联 起 来 。 在 
1.3 发 行 版 本 中 ， 这 个 域 被 初始 化 为 HashMap 实 例 。 在 1.4 发 行 版 本 中 ，Java 平 台 增 加 了 一 个 新 
的 、 被 称 为 IdentityHashMap 的 专用 Map 实 现 。 只 需 将 初始 化 域 的 那 一 行 代码 改变 为 
IdentityHashMap ， 代 替 原 来 的 HashMap ，ThreadLocal 机 制 就 会 变 快 许多 。ThreadLocal 实 现 
曾经 一 度 发 展 为 利用 一 个 没有 实现 Map 接 口 的 高 度 优 化 过 的 存储 结构 ， 但 是 即使 这 样 仍然 不 影 
响 “ 通 过 接口 引用 对 象 ” 的 这 个 观点 。 
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如 果 把 这 个 域 声明 为 HashMap 而 不 是 Map ， 则 无 法 保证 只 改变 一 行 代码 就 足够 了 。 如 果 客 
户 端 代码 已 经 在 Map 接 口 之 外 使 用 了 HashMap 操 作 ， 或 者 把 这 个 映射 (Map) 传递 给 了 一 个 需 
要 HashMap 的 方法 ， 那 么 ， 若 将 该 域 改 变 为 一 个 IdentityHashMap ， 代 码 就 不 再 能 通过 编译 。 
用 接口 类 型 声明 域 “ 让 你 保持 诚实 ”。 


如 果 没 有 合适 的 接口 存在 ， 完 全 可 以 用 类 而 不 是 接口 来 引用 对 象 。 例 如 ， 考 虑 值 类 
(value class) ， 比 如 String 和 BigInteger。 记 住 ， 值 类 很 少 会 用 多 个 实现 编写 。 它 们 通常 是 
final 的 ， 并 且 很 少 有 对 应 的 接口 。 使 用 这 种 值 类 作为 参数 、 变 量 、 域 或 者 返回 类 型 是 再 合适 
不 过 的 了 。 更 一 般 地 讲 ， 如 果 有 具体 类 没有 相关 联 的 接口 ， 不 管 它 是 否 表 示 一 个 值 ， 你 都 没有 ， 
别 的 选择 ， 只 有 通过 它 的 类 来 引用 它 的 对 象 。Random 类 就 属于 这 种 情形 。 


不 存在 适当 接口 类 型 的 第 二 种 情形 是 ， 对 象 属 于 一 个 框架 ， 而 框架 的 基本 类 型 是 类 ， 不 是 
接口 。 如 果 对 象 属于 这 种 基于 类 的 框架 (class-based framework) ， 就 应 该 用 相关 的 基 类 
(base class) (往往 是 抽象 类 ) 来 引用 这 个 对 象 ， 而 不 是 用 它 的 实现 类 。java.util.TimerTask 抽 
象 类 就 属于 这 种 情形 。 


不 存在 适当 接口 类 型 的 最 后 一 种 情形 是 ， 类 实现 了 接口 ， 但 是 它 提 供 了 接口 中 不 存在 的 额 
外 方法 一 一 例如 LinkedHashMap。 如 果 程 序 依赖 于 这 些 额 外 的 方法 ， 这 种 类 就 应 该 只 被 用 来 引 
用 它 的 实例 。 它 很 少 应 该 被 用 作 参 数 类 型 ( 见 第 40 条 ) 。 


以 上 这 些 例子 并 不 全 面 ， 而 只 是 代表 了 一 些 “ 适 合 于 用 类 来 引用 对 象 ”的 情形 。 实 际 上 ， 
给 定 的 对 象 是 否 具 有 适当 的 接口 应 该 是 很 显然 的 。 如 果 是 ， 用 接口 引用 对 象 就 会 使 程序 更 加 
灵活 ， 如 果 不 是 ， 则 使 用 类 层次 结构 中 提供 了 必要 功能 的 最 基础 的 类 。 
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核心 反射 机 制 (core reflection facility) java.lang.reflect, Ht T “通过 程序 来 访问 关于 
已 装载 的 类 的 信息 ”的 能 力 。 给 定 一 个 Class 实 例 ， 你 可 以 获得 Constructor、Method 和 Field 实 
例 ， 分 别 代 表 了 该 Class 实 例 所 表示 的 类 的 Constructor (构造 器 ) Method (方法 ) 和 Field 
( 域 )。 这 些 对 象 提供 了 “通过 程序 来 访问 类 的 成 员 名 称 、 域 类 型 、 方 法 签名 等 信息 ”的 能 力 。 


而 且 ，Constructor、Method 和 Field 实 例 使 你 能 够 通过 反射 机 制 操作 它们 的 底层 对 等 体 : 
通过 调用 Constructor、Method 和 Field 实 例 上 的 方法 ， 可 以 构造 底层 类 的 实例 、 调 用 底层 类 的 
方法 ， 并 访问 底层 类 中 的 域 。 例 如 ，Method.invoke 使 你 可 以 调用 任何 类 的 任何 对 象 上 的 任何 
方法 (遵从 常规 的 安全 限制 )。 反 射 机 制 (reflection) 允许 一 个 类 使 用 另 一 个 类 ， 即 使 当前 者 
被 编译 的 时 候 后 者 还 根本 不 存在 。 然 而 ， 这 种 能 力也 要 付出 代价 : | 


。 丧 失 了 编译 时 类 型 检查 的 好 处 ， 包 括 异 常 检查。 如果 程 序 企图 用 反射 方式 调用 不 存在 的 
或 者 不 可 访问 的 方法 ， 在 运行 时 它 将 会 失败 ， 除 非 采 取 了 特别 的 预防 措施 。 


。 执 行 反射 访问 所 需要 的 代码 非常 笨拙 和 兄长 。 编 写 这 样 的 代码 非常 乏味 ， 阅 读 起 来 也 很 
困难 。 


。 性 能 损失 。 反 射 方法 调用 比 普通 方法 调用 慢 了 许多 。 具 体 慢 了 多 少 ， 这 很 难说 ， 因 为 受 
到 了 多 个 因素 的 影响 。 在 我 的 机 器 上 ， 速 度 的 差异 可 能 小 到 2 倍 ， 也 可 能 大 到 50 倍 。 


核心 反射 机 制 最 初 是 为 了 基于 组 件 的 应 用 创建 工具 而 设计 的 。 这 类 工具 通常 要 根据 需要 装 
载 类 ， 并 且 用 反射 功能 找 出 它们 支持 哪些 方法 和 构造 器 。 这 些 工具 允许 用 户 交互 式 地 构建 出 
访问 这 些 类 的 应 用 程序 ， 但 是 所 产生 出 来 的 这 些 应 用 程序 能 够 以 正常 的 方式 访问 这 些 类 ， 而 
不 是 以 反射 的 方式 。 反 射 功能 只 是 在 设计 时 (design time) 被 用 到 。 通 常 ， 普 通 应 用 程序 在 
运行 时 不 应 该 以 反射 方式 访问 对 象 。 l 


有 一 些 复杂 的 应 用 程序 需要 使 用 反射 机 制 。 这 些 示例 中 包括 类 浏览 器 、 对 象 监视 器 、 代 码 
分 析 工 具 、 解 释 型 的 内 赚 式 系统 。 在 RPC (远程 过 程 调用 ) 系统 中 使 用 反射 机 制 也 是 非常 合 
适 的 ， 这 样 可 以 不 再 需要 存根 编译 器 (stub compiler) 。 如 果 你 对 自己 的 应 用 程序 是 否 也 属于 
这 一 类 应 用 程序 而 感到 怀疑 ， 它 很 有 可 能 就 不 属于 这 一 类 。 


如 果 只 是 以 非常 有 限 的 形式 使 用 反射 机 制 ， 虽 然 也 要 付出 少许 代价 ， 但 是 可 以 获得 许多 好 
处 。 对 于 有 些 程序 ， 它 们 必须 用 到 在 编译 时 无 法 获取 的 类 ， 但 是 在 编译 时 存在 适当 的 接口 或 者 
超 类 ， 通 过 它们 可 以 引用 这 个 类 ( 见 第 52 条 )。 如 果 是 这 种 情况 ， 就 可 以 以 反射 方式 创建 实例 ， 
然后 通过 它们 的 接口 或 者 超 类 ， 以 正常 的 方式 访问 这 些 实例 。 如 果 适 当 的 构造 器 不 带 参 数 ， 
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甚至 根本 不 需要 使 用 java.lang .reflect 包 ，Class.newInstance 方 法 就 已 经 提供 了 所 需 的 功能 。 


例如 ， 下 面 的 程序 创建 了 一 个 Set<String> 实 例 ， 它 的 类 是 由 第 一 个 命令 行 参数 指定 的 。 
该 程序 把 其 余 的 命令 行 参数 插入 到 这 个 集合 中 ， 然 后 打印 该 集合 。 不 管 第 一 个 参数 是 什么 ， 
程序 都 会 打印 出 余下 的 命令 行 参数 ， 其 中 重复 的 参数 会 被 消除 掉 。 这 些 参 数 的 打印 顺序 取决 
于 第 一 个 参数 中 指定 的 类 。 如 果 指 定 “java.util.HashSet”， 显 然 这 些 参数 就 会 以 随机 的 顺序 打 
印 出 来 ， 如 果 指 定 “java.util.TreeSet” ， 则 它们 就 会 按照 字母 顺序 打印 出 来 ， 因 为 TreeSet 中 的 
元 素 是 排 好 序 的 。 相 应 的 代码 如 下 : 


// Reflective instantiation with interface access 
public static void main(String[] args) { 
// Translate the class name into a Class object 
Class<?> cl = null; 
try { 
cl = Class. forName(args[@]); 
} catch(ClassNotFoundException e) { 
System.err.printin("Class not found."); 
System.exit(1); 


// Instantiate the class 

Set<String> s = null; 

try { 

s = (Set<String>) cl.newInstance(); 

} catch(IllegalAccessException e) { 
System.err.printin("Class not accessible."); 
System.exit(1); 

} catch(InstantiationException e) { 
System.err.printin("Class not instantiable."”); 
System.exit(1); 


// Exercise the set 
s.addAl1(Arrays.asList(args).subList(1, args. length)); 
System.out.printin(s); 

} 


尽管 这 个 程序 就 像 一 个 “玩偶 "” ， 但 是 它 所 演示 的 这 种 方法 是 非常 强大 的 。 这 个 玩偶 程序 
可 以 很 容易 地 变 成 一 个 通用 的 集合 测试 器 ， 通 过 侵入 式 地 操作 一 个 或 者 多 个 集合 实例 ， 并 检查 
是 否 遵守 Set 接 口 的 约定 ， 以 此 来 验证 指定 的 Set 实 现 。 同 样 地 ， 它 也 可 以 变 成 一 个 通用 的 集合 
性 能 分 析 工 具 。 实 际 上 ， 它 所 演示 的 这 种 方法 足以 实现 一 个 成 熟 的 服务 提供 者 框架 (service 
provider framework) ( 见 第 1 条 )。 绝 大 多 数 情况 下 ， 使 用 反射 机 制 时 需要 的 也 正 是 这 种 
方法 。 


这 个 示例 演示 了 反射 机 制 的 两 个 缺点 。 第 一 ， 这 个 例子 会 产生 3 个 运行 时 错误 ， 如 果 不 使 
用 反射 方式 的 实例 化 ， 这 3 个 错误 都 会 成 为 编译 时 错误 。 第 二 ， 根 据 类 名 生成 它 的 实例 需要 20 
行 元 长 的 代码 ， 而 调用 一 个 构造 器 可 以 非常 简洁 地 只 使 用 一 行 代码 。 然 而 ， 这 些 缺 点 还 仅仅 
局 限于 实例 化 对 象 的 那 部 分 代码 。 一 旦 对 象 被 实例 化 ， 它 与 其 他 的 Set 实 例 就 难以 区 分 。 在 实 
际 的 程序 中 ， 通 过 这 种 限定 使 用 反射 的 方法 ， 绝 大 部 分 代码 可 以 不 受 影响 ; 
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上 nnn nna 


如 果 试 着 编译 这 个 程序 ， 会 得 到 下 面 的 错误 消息 : 


Note: SetEx.java uses unchecked or unsafe operations. 

Note: Recompile with -Xlint:unchecked for details. 

这 条 警告 与 程序 中 使 用 了 泛 型 有 关 ， 但 它 并 不 能 说 明 真 正 的 问题 。 要 了 解禁 止 这 种 警告 的 
最 佳 方法 ， 请 参见 第 24 条 。 


另 一 个 值得 注意 的 附带 问题 是 ， 这 个 程序 使 用 了 System.exit。 很 少 有 需要 调用 这 个 方法 的 
时 候 ， 它 会 终止 整个 VM (虚拟 机 ) 。 但 是 ， 它 对 于 命令 行 有 效 性 的 非法 终止 是 很 合适 的 。 


类 对 于 在 运行 时 可 能 不 存在 的 其 他 类 、 方 法 或 者 域 的 依赖 性 ， 用 反射 法 进行 管理 ， 这 种 用 
法 是 合理 的 ， 但 是 很 少 使 用 。 如 果 要 编写 一 个 包 ， 并 且 它 运行 的 时 候 必 须 依赖 其 他 某 个 包 的 
多 个 版 本 ， 这 种 做 法 可 能 就 非常 有 用 。 这 种 做 法 就 是 ， 在 支持 包 所 需要 的 最 小 环境 下 对 它 进 
行 编译 ， 通 常 是 最 老 的 版 本 ， 然 后 以 反射 方式 访问 任何 更 加 新 的 类 或 者 方法 。 如 果 企 图 访问 
的 新 类 或 者 新 方法 在 运行 时 不 存在 ， 为 了 使 这 种 方法 有 效 你 还 必须 采取 适当 的 动作 。 所 谓 适 
当 的 动作 ， 可 能 包括 使 用 某 种 其 他 可 替换 的 办 法 来 达到 同样 的 目的 ,或 者 使 用 简化 的 功能 进 
行 处 理 。 


简 而 言 之 ， 反 射 机 制 是 一 种 功能 强大 的 机 制 ， 对 于 特定 的 复杂 系统 编程 任务 ， 它 是 非常 必 
要 的 ， 但 它 也 有 一 些 缺点 。 如 果 你 编写 的 程序 必须 要 与 编译 时 未 知 的 类 一 起 工作 ， 如 有 可 能 ， 
就 应 该 仅仅 使 用 反射 机 制 来 实例 化 对 象 ， 而 访问 对 象 时 则 使 用 编译 时 已 知 的 某 个 接口 或 者 超 类 。 





Java Native Interface (JNI) 允许 Java 应 用 程序 可 以 调用 本 地 方法 (mative method), fit 
谓 本 地 方法 是 指 用 本 地 程序 设计 语言 (比如 C 或 者 C++) 来 编写 的 特殊 方法 。 本 地 方法 在 本 地 
语言 中 可 以 执行 任意 的 计算 任务 ， 并 返回 到 Java 程 序 设计 语言 。 


从 历史 上 看 ， 本 地 方法 主要 有 三 种 用 途 。 它 们 提供 了 “访问 特定 于 平台 的 机 制 ” 的 能 力 ， 
比如 访问 注册 表 (registry) 和 文件 锁 (file lock)。 它 们 还 提供 了 访问 遗留 代码 库 的 能 力 ， 从 
而 可 以 访问 遗留 数据 (legacy data)。 最 后 ， 本 地 方法 可 以 通过 本 地 语言 ， 编 写 应 用 程序 中 注 
重 性 能 的 部 分 ， 以 提高 系统 的 性 能 。 


使 用 本 地 方法 来 访问 特定 于 平台 的 机 制 是 合法 的 ， 但 是 随 着 Java 平 台 的 不 断 成 熟 ， 它 提供 
了 越 来 越 多 以 前 只 有 在 宿主 平台 上 才 拥 有 的 特性 。 例 如 ，1.4 发 行 版 本 中 新 增加 的 java.util. 
prefs 包 ， 提 供 了 注册 表 的 功能 ，1.6 发 行 版 本 中 增加 了 java.awt.SystemTray， 提 供 了 访问 桌面 
系统 托盘 区 的 能 力 。 使 用 本 地 方法 来 访问 遗留 代码 也 是 合法 的 。 


使 用 本 地 方法 来 提高 性 能 的 做 法 不 值得 提倡 。 在 早期 的 发 行 版 本 中 (1.3 发 行 版 本 之 前 )， 
这 样 做 往往 是 很 有 必要 的 ， 但 是 JVM 实 现 变 得 越 来 越 快 了 。 对 于 大 多 数 任务 ， 现 在 即使 不 使 
用 本 地 方法 也 可 以 获得 与 之 相当 的 性 能 。 举 例 来 说 ， 当 Java 1.1 发 行 版 本 中 增加 了 java:math 
时 ，BigInteger 是 在 一 个 用 C 编 写 的 快速 多 精度 运算 库 的 基础 上 实现 的 。 在 当时 ， 为 了 获得 足 
够 的 性 能 这 样 做 是 必要 的 。 在 1.3 发 行 版 本 中 ，BigInteger 则 完全 用 Java 重 写 了 ， 并 且 进行 了 
精心 的 性 能 调 优 。 即 便 如 此 ， 新 的 版 本 还 是 比 原来 的 版 本 更 快 ， 在 这 些 年 间 ，VM 也 已 经 变 
得 更 快 了 。 


使 用 本 地 方法 有 一 些 严 重 的 缺点 。 因 为 本 地 语言 不 是 安全 的 〈 见 第 39 条 ) ， 所 以 ， 使 用 本 
地 方法 的 应 用 程序 也 不 再 能 免 受 内 存 毁 坏 错 误 的 影响 。 因 为 本 地 语言 是 与 平台 相关 的 ， 使 用 
本 地 方法 的 应 用 程序 也 不 再 是 可 自由 移植 的 。 使 用 本 地 方法 的 应 用 程序 也 更 难 调试 。 在 进入 
和 退出 本 地 代码 时 ， 需 要 相关 的 固定 开销 ， 所 以 ， 如 果 本 地 代码 只 是 做 少量 的 工作 ， 本 地 方 
法 就 可 能 降低 (decrease) 性 能 。 最 后 一 点 ， 需 要 “胶合 代码 ”的 本 地 方法 编写 起 来 单调 乏味 ， 
并 且 难 以 阅读 。 

总 而 言 之 , 在 使 用 本 地 方法 之 前 务必 三 思 。 极 少数 情况 下 会 需要 使 用 本 地 方法 来 提高 性 能 。 
如 有 果 你 必须 要 使 用 本 地 方法 来 访问 底层 的 资源 ， 或 者 遗留 代码 库 ， 也 要 尽 可 能 少 用 本 地 代码 ， 
并 且 要 全 面 进行 测试 。 本 地 代码 中 的 一 个 Bug 就 有 可 能 破坏 整个 应 用 程序 。 
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有 三 条 与 优化 有 关 的 格言 是 每 个 人 都 应 该 知道 的 。 这 些 格言 我 们 可 能 已 经 耳熟能详 , 但 是 ， 
如 果 对 它们 还 不 太 熟 悉 ， 请 看 下 面 : 


很 多 计算 上 的 过 失 都 被 归 符 于 效率 (没有 必要 达到 的 效率 )， 而 不 是 任何 其 他 的 原因 一 一 
LEH AUK, 


——William A. Wulf[Wulf72] 


KRLHRARLOH—EMDMRK, AOVHMHAT, TARH RLT Ah MAh 
根源 。 
——Donald E. Knuth[Knuth74] 
在 优化 方面 ， 我 们 应 该 遵守 两 条 规则 : 
规则 1; 不 要 进行 优化 。 


规则 2 ( 仅 针对 专家 ): 还 是 不 要 进行 优化 一 一 也 就 是 说 ， 在 你 还 没有 绝对 清晰 的 未 优化 方 
案 之 前 ， 请 不 要 进行 优化 。 


—M. A. Jackson[Jackson75] 


所 有 这 些 格 言 都 比 Java 程 序 设计 语言 的 出 现 早 了 20 年 。 它 们 讲述 了 一 个 关于 优化 的 深刻 真 
理 : 优化 的 棘 大 于 利 ， 特 别 是 不 成 熟 的 优化 。 在 优化 过 程 中 ， 产 生 的 软件 可 能 既 不 快速 ， 也 
不 正确 ， 而 且 还 不 容易 修正 。 l 


不 要 因为 性 能 而 牺牲 合理 的 结构 。 要 努力 编写 好 的 程序 而 不 是 快 的 程序 。 如 果 好 的 程序 不 
够 快 ， 它 的 结构 将 使 它 可 以 得 到 优化 。 好 的 程序 体现 了 信息 隐藏 (information hiding) 的 原 
WW: 只 要 有 可 能 ， 它 们 就 会 把 设计 决策 集中 在 单个 模块 中 ， 因 此 ， 可 以 改变 单个 决策 ， 而 不 
会 影响 到 系统 的 其 他 部 分 ( 见 第 13 条 )。 


这 并 不 意味 着 ， 在 完成 程序 之 前 就 可 以 忽略 性 能 问题 。 实 现 上 的 问题 可 以 通过 后 期 的 优化 
而 得 到 修正 ， 但 是 ， 遍 布 全 局 并 且 限 制 性 能 的 结构 缺陷 几乎 是 不 可 能 被 改正 的 ， 除 非 重 新 编 
写 系 统 。 在 系统 完成 之 后 再 改变 设计 的 某 个 基本 方面 ， 会 导致 系统 的 结构 很 不 好 ， 从 而 难以 


维护 和 改进 。 因 此 ， 必 须 在 设计 过 程 中 考虑 到 性 能 问题 。 


努力 避免 那些 限制 性 能 的 设计 决策 。 当 一 个 系统 设计 完成 之 后 ， 其 中 最 难以 更 改 的 组 件 是 
那些 指定 了 模块 之 间 交 互 关 系 以 及 模块 与 外 界 交 互 关 系 的 组 件 。 在 这 些 设计 组 件 之 中 ， 最 主 
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要 的 是 API、 线 路 层 (wire-level) 协议 以 及 永久 数据 格式 。 这 些 设 计 组 件 不 仅 在 事后 难以 其 
至 不 可 能 改变 ， 而 且 它们 都 有 可 能 对 系统 本 该 达到 的 性 能 产生 严重 的 限制 。 


要 考虑 API 设 计 决 策 的 性 能 后 果 。 使 公有 的 类 型 成 为 可 变 的 《mnutable) ， 这 可 能 会 导致 大 
量 不 必要 的 保护 性 拷贝 ( 见 第 39 条 )。 同 样 地 ， 在 适合 使 用 复合 模式 的 公有 类 中 使 用 继承 ， 会 
把 这 个 类 与 它 的 超 类 永远 地 束缚 在 一 起 ， 从 而 人 为 地 限制 了 子 类 的 性 能 ( 见 第 16 条 )。 最 后 一 
个 例子 ， 在 API 中 使 用 实现 类 型 而 不 是 接口 ， 会 把 你 束缚 在 一 个 具体 的 实现 上 ， 即 使 将 来 出 现 
更 快 的 实现 你 也 无 法 使 用 〈 见 第 52 条 ) 。 


API 设 计 对 于 性 能 的 影响 是 非常 实际 的 。 考 虑 java.awt.Component 类 中 的 getSize 方 法 。 这 
个 决定 就 是 ， 这 个 注重 性 能 的 方法 将 返回 Dimension 实 例 ， 与 此 密切 相关 的 决定 是 ，Dimension 
实例 是 可 变 的 ， 迫 使 这 个 方法 的 任何 实现 都 必须 为 每 个 调用 分 配 一 个 新 的 Dimension 实 例 。 尽 
管 在 现代 VM 上 分 配 小 对 象 的 开销 并 不 大 ， 但 是 分 配 数 百 万 个 不 必要 的 对 象 仍然 会 严重 地 损害 
性 能 。 


在 这 种 情况 下 ， 有 有 几 种 可 供 选 择 的 替换 方案 。 理 想 情况 下 ，Dimension 应 该 是 不 可 变 的 
( 见 第 15 条 ) ， 另 一 种 方案 是 ， 用 两 个 方法 来 替换 getSize 方 法 ， 它 们 分 别 返 回 Dimension 对 象 
的 单个 基本 组 件 。 实 际 上 ， 在 1.2 发 行 版 本 中 ， 出 于 性 能 方面 的 原因 ， 两 个 这 样 的 方法 已 经 被 
加 入 到 Component API 中。 然而， 原先 的 客户 端 代码 仍然 可 以 使 用 getSize 方 法 ， 但 是 仍然 要 
承受 原始 API 设 计 决 策 所 带 来 的 性 能 影响 。 


幸运 的 是 ， 一 般 而 言 ， 好 的 API 设 计 也 会 带 来 好 的 性 能 。 为 获得 好 的 性 能 而 对 API 进 行 包 
装 ， 这 是 一 种 非常 不 好 的 想法 。 导 致 你 对 API 进 行 包 装 的 性 能 因素 可 能 会 在 平台 未 来 的 发 行 版 
本 中 ， 或 者 在 将 来 的 底层 软件 中 不 复 存 在 ， 但 是 被 包装 的 API 以 及 由 它 引起 的 问题 将 永远 困扰 
着 你 。 


一 旦 谨慎 地 设计 了 程序 ， 并 且 产 生 了 一 个 清晰 、 简 明 、 结 构 良 好 的 实现 ， 那 么 就 到 了 该 考 
虑 优化 的 时 候 了 ， 假 定 此 时 你 对 于 程序 的 性 能 还 不 满意 。 


回想 一 下 Jackson 的 两 条 优化 规则 :“ 不 要 优化 ”以 及 “( 仅 针对 专家 ) 还 是 不 要 优化 ”"。 他 
可 以 再 增加 一 条 : 在 每 次 试图 做 优化 之 前 和 之 后 ， 要 对 性 能 进行 测量 ;你 可 能 会 惊讶 于 自己 
的 发 现 。 试 图 做 的 优化 通常 对 于 性 能 并 设 有 明显 的 影响 ， 有 时 候 甚 至 会 使 性 能 变 得 更 差 。 主 
要 的 原因 在 于 ， 要 猜 出 程序 把 时 间 花 在 哪些 地 方 并 不 容易 。 你 认为 程序 慢 的 地 方 可 能 并 没有 
问题 ， 这 种 情况 下 实际 上 是 在 浪费 时 间 去 尝试 优化 。 大 多 数 人 认为 : 程序 把 80% 的 时 间 花 在 
20% 的 代码 上 了 。 


性 能 剖析 工具 有 助 于 你 决定 应 该 把 优化 的 重心 放 在 哪里 。 这 样 的 工具 可 以 为 你 提供 运行 时 
的 信息 ， 比 如 每 个 方法 大 致 上 花费 了 多 少时 间 、 它 被 调用 多 少 次 。 除 了 确定 优化 的 重点 之 外 ， 
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它 还 可 以 警告 你 是 否 需 要 改变 算法 。 如 果 一 个 平方 级 (或 更 差 ) 的 算法 潜藏 在 程序 中 ， 无 论 
怎么 调整 和 优化 都 很 难 解决 问题 。 你 必须 用 更 有 效 的 算法 来 替换 原来 的 算法 。 系 统 中 的 代码 
越 多 ， 使 用 性 能 剖析 器 就 显得 越发 重要 。 这 就 好 像 要 在 一 堆 干 草 中 寻找 一 根 针 : 这 堆 干草 越 
大 ， 使 用 金属 探测 器 就 越 有 用 。JDK 带 了 简单 的 性 能 剖析 器 ， 现 代 的 IDE 也 提供 了 更 加 成 熟 的 
性 能 剖析 工具 。 


在 Java 平 台 上 对 优化 的 结果 进行 测量 ， 比 在 其 他 的 传统 平台 上 更 有 必要 ， 因 为 Java 程 序 设 
计 语 言 没 有 很 强 的 性 能 模型 (performance model) 。 各 种 基本 操作 的 相对 开销 也 没有 明确 定 
义 。 程 序 员 所 编写 的 代码 与 CPU 执行 的 代码 之 间 存 在 “语义 沟 (semantic gap)”， 而 且 这 条 语 
义 沟 比 传统 编译 语言 中 的 更 大 ， 这 使 得 要 想 可 靠 地 预测 出 任何 优化 的 性 能 结果 都 非常 困难 。 
大 量 流传 的 关于 性 能 的 说 法 最 终 都 被 证 明 为 半 真 半 假 , 或 者 根本 就 不 正确 。 


不 仅 Java 的 性 能 模型 未 得 到 很 好 的 定义 ,而 且 在 不 同 的 VM 实现 ,或 者 不 同 的 发 行 版 本 ， 
以 及 不 同 的 处 理 器 ， 在 它们 这 些 当中 也 都 各 不 相同 。 如 果 将 要 在 多 个 JVM 实 现 和 多 种 硬件 平 
人 台 上 运行 程序 ， 很 重要 的 一 点 是 ， 需 要 在 每 个 Java 实 现 上 测量 优化 效果 。 有 时候， 还 必须 在 从 
不 同 JVM 实 现 或 者 硬件 平台 上 得 到 的 性 能 结果 之 中 进行 权衡 。 


总 而 言 之 , 不 要 费力 去 编写 快速 的 程序 一 一 应 该 努力 编写 好 的 程序 ,速度 自然 会 随 之 而 来 。 
在 设计 系统 的 时 候 ， 特 别 是 在 设计 API、 线 路 层 协议 和 永久 数据 格式 的 时 候 ， 一 定 要 考虑 性 能 
的 因素 。 当 构建 完 系统 之 后 ， 要 测量 它 的 性 能 。 如 果 它 足够 快 ， 你 的 任务 就 完成 了 。 如 果 不 
够 快 ， 则 可 以 在 性 能 剖析 器 的 帮助 下 ， 找 到 问题 的 根源 ， 然 后 设法 优化 系统 中 相关 的 部 分 。 
第 一 个 步 又 是 检查 所 选择 的 算法 : 再 多 的 低层 优化 也 无 法 弥补 算法 的 选择 不 当 。 必 要 时 重复 
这 个 过 程 ， 在 每 次 改变 之 后 都 要 测量 性 能 ， 直 到 满意 为 止 。 





Java 平 台 建 立 了 一 整套 很 好 的 命名 惯例 (naming convention) ， 其 中 有 许多 命名 惯例 包含 
在 了 《The Java Language Specification) [JILS，6.8] 中 。 不 严格 地 讲 ， 这 些 命名 惯例 分 为 两 大 
类 : 字面 的 (typographical) 和 语法 的 (grammatical), 


字面 的 命名 惯例 比较 少 ， 但 也 涉及 包 、 类 、 接 口 、 方 法 、 域 和 类 型 变量 。 应 该 尽量 不 违反 
这 些 惯 例 ， 不 到 万 不 得 已 ， 千 万 不 要 违反 。 如 果 API 违 反 了 这 些 惯 例 ， 它 使 用 起 来 可 能 会 很 困 
难 。 如 果实 现 违反 了 它们 ， 它 可 能 会 难以 维护 。 在 这 两 种 情况 下 ， 违 反 惯例 都 会 潜在 地 给 使 
用 这 些 代码 的 其 他 程序 员 带 来 困惑 和 苦恼 ， 并 且 使 他 们 做 出 错误 的 假设 ， 造 成 程序 出 错 。 本 
条 目 将 对 这 些 惯 例 做 简要 的 介绍 。 


包 的 名 称 应 该 是 层次 状 的 ， 用 句号 分 隔 每 个 部 分 。 每 个 部 分 都 包括 小 写字 母 和 数字 (很 少 
使 用 数字 )。 任 何 将 在 你 的 组 织 之 外 使 用 的 包 ， 其 名 称 都 应 该 以 你 的 组 织 的 Internet 域 名 开头 ， 
并 且 顶 级 域名 放 在 前 面 ， 例 如 edu.cmu、com.sun、gov.nsa。 标 准 类 库 和 一 些 可 选 的 包 ， 其 名 
称 以 java 和 javax 开 头 ， 这 属于 这 一 规则 的 例外 。 用 户 创 建 的 包 的 名 称 绝 不 能 以 java 和 javax 开 
头 。 关 于 将 Internet 域 名 转换 为 包 名 称 前 缀 的 详细 规则 ， 请 参见 《The Java Language 
Specification) [JLS, 7.7]。 


包 名 称 的 其 余部 分 应 该 包括 一 个 或 者 多 个 描述 该 包 的 组 成 部 分 。 这 些 组 成 部 分 应 该 比较 简 
短 ,, 通常 不 超过 8 个 字符 。 鼓 励 使 用 有 意义 的 缩写 形式 ， 例 如 ， 使 用 util 而 不 是 utilities。 只 取 
首 字 母 的 缩写 形式 也 是 可 以 接受 的 ， 例 如 awt。 每 个 组 成 部 分 通常 都 应 该 由 一 个 单词 或 者 一 个 
缩写 词组 成 。 


许多 包 的 名 称 中 除了 Internet 域 名 就 只 有 一 个 组 成 部 分 。 大 型 工具 包 可 适当 使 用 额外 的 组 
成 部 分 ， 它 们 的 规模 决定 了 应 该 分 割 成 非 正 式 的 层次 结构 。 例 如 ，javax.swing 包 有 着 非常 丰 
富 的 包 层 次 ， 如 javax.swing.plaf.metal。 这 样 的 包 通 常 被 称 为 子 包 ， 尽 管 Java 语 言 并 没有 提供 
对 包 层 次 的 支持 。 


类 和 接口 的 名 称 ， 包 括 枚 举 和 注解 类 型 的 名 称 ， 都 应 该 包括 一 个 或 者 多 个 单词 ， 每 个 单词 
的 首 字 母 大 写 ， 例 如 Timer 和 TimerTask。 应 该 尽量 避免 用 缩写 ， 除 非 是 一 些 首 字母 缩写 和 一 
些 通用 的 缩写 ， 比 如 max 和 min。 对 于 首 字母 缩写 ， 到 底 应 该 全 部 大 写 还 是 只 有 首 字母 大 写 ， 
没有 统一 的 说 法 。 虽 然 大 写 更 常见 一 些 ， 但 还 是 强烈 建议 采用 仅 有 首 字母 大 写 的 形式 : 即使 
连续 出 现 多 个 首 字母 缩写 的 形式 ， 你 仍然 可 以 区 分 出 一 个 单词 的 起 始 处 和 结束 处 。 下 面 这 两 
个 类 名 你 更 愿意 看 到 哪 一 个 ，HTTPURL 还 是 HttpUrl? 


方法 和 域 的 名 称 与 类 和 接口 的 名 称 一 样 ， 都 遵守 相同 的 字面 惯例 ， 只 不 过 方法 或 者 域 的 名 
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称 的 第 一 个 字母 应 该 小 写 ， 例 如 remove、ensureCapacity。 如 果 由 首 字母 缩写 组 成 的 单词 是 一 
个 方法 或 者 域名 称 的 第 一 个 单词 ， 它 就 应 该 是 小 写 形式 。 


上 述 规则 的 唯一 例外 是 “常量 域 "， 它 的 名 称 应 该 包含 一 个 或 者 多 个 大 写 的 单词 ， 中 间 用 
下 划 线 符号 隔 开 ， 例 如 VALUES 或 NEGATIVE_INFINITY。 常 量 域 是 个 静态 final 域 ， 它 的 值 
是 不 可 变 的 。 如 果 静 态 final 域 有 基本 类 型 ， 或 者 有 不 可 变 的 引用 类 型 ( 见 第 15 条 ) ， 它 就 是 个 
常量 域 。 例 如 ， 枚 举 常量 是 常量 域 。 如 果 静 态 final 域 有 个 可 变 的 引用 类 型 ， 若 被 引用 的 对 象 
是 不 可 变 的 ， 它 也 仍然 可 以 是 个 常量 域 。 注 意 ， 常 量 域 是 唯一 推荐 使 用 下 划 线 的 情形 。 


局 部 变量 名 称 的 字面 命名 惯例 与 成 员 名 称 类 似 ， 只 不 过 它 也 允许 缩写 ， 单 个 字符 和 短 字符 
序列 的 意义 取决 于 局 部 变量 所 在 的 上 下 文 环境 ,例如 i、xref 和 houseNumber。 


类 型 参数 名 称 通常 由 单个 字母 组 成 。 这 个 字母 通常 是 以 下 五 种 类 型 之 一 : T 表 示 任 意 的 类 
型 ，E 表 示 集 合 的 元 素 类 型 ， 和 X 表 示 异 常 。 任 何 类 型 的 序列 可 以 
ÆT. U- VRATI. T2. T3. 


为 了 快速 查阅 ， 表 8-1 列 出 了 字面 惯例 的 例子 。 


表 8-1 字面 惯例 的 例子 


标识 符 类 型 例子 
包 com.google.inject, org.joda.time.format 

类 或 者 接口 Timer, FutureTask, LinkedHashMap, HttpServlet 
方法 或 者 域 remove, ensureCapacity, getCrc 

常量 域 MIN_VALUE, NEGATIVE_INFINITY 

局 部 变量 i, xref, houseNumber 

类 型 参数 T, EB, K, V, X, Tl, T2 


语法 命名 惯例 比 字面 惯例 更 加 灵活 ， 也 更 有 争议 。 对 于 包 而 言 ， 没 有 语法 命名 惯例 。 类 
(包括 枚 举 类 型 ) 通常 用 一 个 名 词 或 者 名 词 短 语 命 名 ， 例 如 Timer、BufferedWriter 或 者 
ChessPiece。 接 口 的 命名 与 类 相似 ， 例 如 Collection 或 Comparator， 或 者 用 一 个 以 “-able” 或 
“-ible” 结 尾 的 形容 词 来 命名 ， 例 如 Runnable、Iterable 或 者 Accessible。 由 于 注解 类 型 有 这 么 多 
用 处 ， 因 此 没有 单独 安排 词类 。 名 词 、 动 词 、 介 词 和 形容 词 都 很 常用 ， 例 如 BindingAnnotation、 
Inject、ImplementedBy 或 者 Singleton 。 


执行 某 个 动作 的 方法 通常 用 动词 或 者 动词 短语 来 命名 ， 例 如 append 或 drawImage。 对 于 返 
回 boolean 值 的 方法 ， 其 名 称 往往 以 单词 “is” 开 头 ， 很 少 用 has， 后 面 跟 名 词 或 名 词 短 语 ， 或 
者 任何 具有 形容 词 功 能 的 单词 或 短语 ， 例 如 isDigit、isProbablePrime、isEmpty、isEnabled 或 
者 hasSiblings。 


210 PSE 


如 果 方 法 返回 被 调用 对 象 的 一 个 非 boolean 的 函数 或 者 属性 ， 它 通常 用 名 词 、 名 词 短语 ， 
或 者 以 动词 “get” 开 头 的 动词 短语 来 命名 ， 例 如 size、hashCode 或 者 getTime。 有 一 种 声音 认 
为 ， 只 有 第 三 种 形式 (以 “get” 开 头 ) 才 可 以 接受 ， 但 是 这 种 说 法 没有 什么 根据 。 前 两 种 形 
式 往往 会 产生 可 读 性 更 好 的 代码 ， 例 如 : 

if (car.speed() > 2 * SPEED_LIMIT) 

generateAudibleAlert("Watch out for cops!"); 

如 果 方 法 所 在 的 类 是 个 Bean[JavaBeans]， 就 要 强制 使 用 以 “get” 开 头 的 形式 ， 而 且 ， 如 
果 考 虑 将 来 要 把 这 个 类 转变 成 Bean， 这 么 做 也 是 明智 的 。 另 外 ， 如 果 这 个 类 包含 一 个 方法 用 
于 设置 同样 的 属性 ， 则 强烈 建议 采用 这 种 形式 。 在 这 种 情况 下 ， 这 两 个 方法 应 该 被 命名 为 
getAttribute 和 setAttribute 。 


有 些 方法 的 名 称 值得 专门 提 及 。 转 换 对 象 类 型 的 方法 、 返 回 不 同类 型 的 独立 对 象 的 方法 ， 
通常 被 称 为 ttType， 例 如 toString 和 toArray。 返 回 视图 (view， 见 第 5 条 ， 视 图 的 类 型 不 同 于 
接收 对 象 的 类 型 ) 的 方法 通常 被 称 为 asType， 例 如 asList。 返 回 一 个 与 被 调用 对 象 同 值 的 基本 
类 型 的 方法 ， 通常 被 称 为 typeValue ， 例 如 intValue。 静 态 工 厂 的 常用 名 称 为 valueOf、of、 
getInstance、newJInstance、getType 和 NewType ( 见 第 1 条 ) 。 


域名 称 的 语法 惯例 没有 很 好 地 建立 起 来 ， 也 没有 类 、 接 口 和 方法 名 称 的 惯例 那么 重要 ， 因 
为 设计 良好 的 API 很 少 会 包含 暴露 出 来 的 域 。boolean 类 型 的 域 命名 与 boolean 类 型 的 访问 方法 
(accessor method) 很 类 似 ， 但 是 省 去 了 初始 的 “is”， 例 如 initialized 和 composite。 其 他 类 型 
的 域 通 常用 名 词 或 者 名 词 短语 来 命名 ， 比 如 height、digits 或 bodyStyle。 局 部 变量 的 语法 惯例 
类 似 于 域 的 语法 惯例 ， 但 是 更 弱 一 些 。 


总 而 言 之 , 把 标准 的 命名 惯例 当 作 一 种 内 在 的 机 制 来 看 待 , 并 且 学 着 用 它们 作为 第 二 特性 。 
字面 惯例 是 非常 直接 和 明确 的 ， 语 法 惯例 则 更 复杂 ， 也 更 松散 。 下 面 这 句 话 引 自 《The Java 
Language Specification》[JLS, 6.8]:“ 如 果 长 期 养 成 的 习惯 用 法 与 此 不 同 ， 请 不 要 盲目 遵从 这 
些 命名 惯例 ”请 运用 常识 。 





第 9 章 
OR 


充分 发 挥 异 常 的 优点 ， 可 以 提高 程序 的 可 读 性 、 可 靠 性 和 可 维护 性 ， 如 果 使 用 不 当 ， 它 
们 也 会 带 来 负面 影响 。 本 章 提 供 了 一 些 关 于 有 效 使 用 异常 的 指导 原则 。 


第 57 条 ， 只 针对 异常 的 情况 
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某 一 天 ， 如 果 你 不 走运 的 话 ， 可 能 会 碰 到 下 面 这 样 的 代码 : 


// Horrible abuse of exceptions. Don't ever do this! 
try { 
int i = 0; 
while(true) 
range[i++].climb(); 
} catch(ArrayIndexOutOfBoundsException e) { 
} 


这 段 代 码 有 什么 作用 ? 看 起 来 根本 不 明显 ， 这 正 是 它 没有 真正 被 使 用 的 原因 ( 见 第 55 条 )。 
事实 证 明 ， 作 为 一 个 要 对 数组 元 素 进行 遍历 的 实现 方式 ， 它 的 构想 是 非常 拙劣 的 。 当 这 个 循 
环 企图 访问 数组 边界 之 外 的 第 一 个 数组 元 素 时 ， 用 抛 出 (throw)、 捕 获 (catch) 、 忽 略 
ArrayIndexOutOfBoundsException 的 手段 来 达到 终止 无 限 循环 的 目的 。 假 定 它 与 数组 循环 的 
标准 模式 是 等 价 的 ， 对 于 任何 一 个 Java 程 序 员 来 说 ， 下 面 的 标准 模式 一 看 就 会 明白 : 

for (Mountain m : range) 

m.climb(); 

那么 ， 为 什么 有 人 会 优先 使 用 基于 异常 的 模式 ， 而 不 是 用 行 之 有 效 的 模式 呢 ? 这 是 被 误导 
了 了， 他 们 企图 利用 Java 的 错误 判断 机 制 来 提高 性 能 ， 因 为 VM 对 每 次 数组 访问 都 要 检查 越界 情 
况 ， 所 以 他 们 认为 正常 的 循环 终止 测试 被 编译 器 隐藏 了 ， 但 在 for-each 循 环 中 仍然 可 见 ， 这 无 
疑 是 多 余 的 ， 应 该 避免 。 这 种 想法 有 三 个 错误 ， 


"因为 异常 机 制 的 设计 初衷 是 用 于 不 正常 的 情形 ， 所 以 很 少 会 有 JVM 实 现 试图 对 它们 进行 
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优化 ， 使 得 与 显 式 的 测试 一 样 快速 。 
。 把 代码 放 在 try-catch 块 中 反而 阻止 了 现代 JVM 实 现 本 来 可 能 要 执行 的 某 些 特定 优化 。 


。 对 数组 进行 遍历 的 标准 模式 并 不 会 导致 元 余 的 检查 。 有 些 现代 的 JVM 实 现 会 将 它们 优 
化 掉 。 


实际 上 ， 在 现代 的 JVM 实 现 上 ， 基 于 异常 的 模式 比 标准 模式 要 慢 得 多 。 在 我 的 机 器 上 ， 
对 于 一 个 有 100 个 元 素 的 数组 ， 基 于 异常 的 模式 比 标准 模式 慢 了 2 倍 。 


基于 异常 的 循环 模式 不 仅 模糊 了 代码 的 意图 ， 降 低 了 它 的 性 能 ， 而 且 它 还 不 能 保证 正常 工 
作 ! 如 果 出 现 了 不 相关 的 Bug， 这 个 模式 会 悄悄 地 失效 ， 从 而 掩盖 了 这 个 Bug， 极 大 地 增加 了 
调试 过 程 的 复杂 性 。 假 设 循环 体 中 的 计算 过 程 调 用 了 一 个 方法 ， 这 个 方法 执行 了 对 某 个 不 相 
关 数 组 的 越界 访问 。 如 果 使 用 合理 的 循环 模式 ， 这 个 Bug 会 产生 未 被 捕捉 的 异常 ， 从 而 导致 线 
程 立即 结束 ， 产 生 完整 的 堆栈 轨迹 。 如 果 使 用 这 个 误导 的 基于 异常 的 循环 模式 ， 与 这 个 Bug 相 
关 的 异常 将 会 被 捕捉 到 ， 并 且 被 错误 地 解释 为 正常 的 循环 终止 条 件 。 


这 个 例子 的 教训 很 简单 : 顾名思义 ， 异 常 应 该 只 用 于 异常 的 情况 下 ; 它们 永远 不 应 该 用 于 
正常 的 控制 流 。 更 一 般 地 ， 应 该 优先 使 用 标准 的 、 容 易 理解 的 模式 ， 而 不 是 那些 声称 可 以 提 
供 更 好 性 能 的 、 和 弄巧成拙 的 方法 。 即 使 真 的 能 够 改进 性 能 ， 面 对 平台 实现 的 不 断 改 进 ， 这 种 
模式 的 性 能 优势 也 不 可 能 一 直 保 持 。 然 而 ， 由 这 种 过 度 聪 明 的 模式 带 来 的 微妙 的 Bug， 以 及 维 
护 的 痛苦 却 依 然 存 在 。 


这 条 原则 对 于 API 设 计 也 有 启发 。 设 计 良 好 的 API 不 应 该 强 连 它 的 客户 端 为 了 正常 的 控制 
流 而 使 用 有 异常。 如 果 类 具有 “状态 相关 (state-dependent)” 的 方法 ， 即 只 有 在 特定 的 不 可 预 
知 的 条 件 下 才 可 以 被 调用 的 方法 ， 这 个 类 往往 也 应 该 有 个 单独 的 “状态 测试 (state-testing)” 
方法 ， 即 指示 是 否 可 以 调用 这 个 状态 相关 的 方法 。 例 如 ，Iterator 接 口 有 一 个 “状态 相关 ”的 
next 方 法 ， 和 相应 的 状态 测试 方法 hasNext。 这 使 得 利用 传统 的 for 循 环 (以 及 for-each 循 环 ， 
在 这 里 ， 是 在 内 部 使 用 hasNext 方 法 ) 对 集合 进行 迭代 的 标准 模式 成 为 可 能 : 


for (Iterator<Foo> i = collection.iterator(); i.hasNext(); ) { 
Foo foo = i.next(); 


} 


如 果 Iterator 缺 少 hasNext 方 法 ， 客 户 端 将 被 迫 改 用 下 面 的 做 法 : 


// Do not use this hideous code for iteration over a collection! 
try { 
Iterator<Foo> i = collection.iterator(); 
while(true) { 
Foo foo = i.next(); 
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} 
} catch (NoSuchETementException e) { 
} 


这 应 该 非常 类 似 于 本 条 目 刚 开始 时 对 数组 进行 迭代 的 例子 。 除 了 代码 繁琐 且 令 人 误解 之 
外 ， 这 个 基于 异常 的 模式 可 能 执行 起 来 也 比 标准 模式 更 差 ， 并且 还 可 能 掩盖 系统 中 其 他 不 相 
关 部 分 中 的 Bug。 


另 一 种 提供 单独 的 状态 测试 方法 的 做 法 是 ， 如 果 “ 状 态 相 关 的 ”方法 被 调用 时 ， 该 对 象 处 
于 不 适当 的 状态 之 中 ， 它 就 会 返回 一 个 可 识别 的 值 ， 比 如 null。 这 种 方法 对 于 Iterator 而 言 并 不 
合适 ， 因 为 null 是 next 方 法 的 合法 返回 值 。 


对 于 “状态 测试 方法 ”和 “可 识别 的 返回 值 ”这 两 种 做 法 ， 有 些 指导 原则 可 以 帮助 你 在 两 
者 之 中 做 出 选择 。 如 果 对 象 将 在 缺少 外 部 同步 的 情况 下 被 并 发 访问 ， 或 者 可 被 外 界 改 变 状态 ， 
使 用 可 被 识别 的 返回 值 可 能 是 很 有 必要 的 ， 因 为 在 调用 “状态 测试 ”方法 和 调用 对 应 的 “ 状 
态 相 关 ” 方 法 的 时 间 间 隔 之 中 ， 对 象 的 状态 有 可 能 会 发 生变 化 。 如 果 单 独 的 “状态 测试 ” 方 
法 必须 重复 “状态 相关 ”方法 的 工作 ， 从 性 能 的 角度 考虑 ， 就 应 该 使 用 可 被 识别 的 返回 值 。 
如 果 所 有 其 他 方面 都 是 等 同 的 ， 那 么 “状态 测试 ”方法 则 略 优 于 可 被 识别 的 返回 值 。 它 提供 
了 更 好 的 可 读 性 ， 对 于 使 用 不 当 的 情形 ， 可 能 更 加 易于 检测 和 改正 : 如果 忘 了 去 调用 状态 测 
试 方法 ， 状 态 相关 的 方法 就 会 抛 出 异常 ， 使 这 个 Bug 变 得 很 明显 ， 如 果 忘 了 去 检查 可 识别 的 返 
回 值 ， 这 个 Bug 就 很 难 会 被 发 现 。 


总 而 言 之 ， 异 常 (exception) 是 为 了 在 异常 情况 下 使 用 而 设计 的 。 不 要 将 它们 用 于 普通 
的 控制 流 ， 也 不 要 编写 迫使 它们 这 么 做 的 API。 
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Java 程 序 设计 语言 提供 了 三 种 可 抛 出 结构 (throwable ) : 受 检 的 异常 (checked exception), 
运行 时 异常 (run-time exception) 和 错误 (error)。 关 于 什么 时 候 适 合 使 用 哪 种 可 抛 出 结构 ， 
程序 员 中 间 存 在 一 些 困 惑 。 虽 然 这 项 决定 并 不 总 是 那么 清晰 ， 但 还 是 有 些 一 般 性 的 原则 提出 
TRADES. 


在 决定 使 用 受 检 的 异常 或 是 未 受 检 的 异常 时 ， 主 要 的 原则 是 : 如 果 期 望 调用 者 能 够 适当 地 
恢复 ， 对 于 这 种 情况 就 应 该 使 用 受 检 的 异常 。 通 过 抛 出 受 检 的 异常 ， 强 迫 调 用 者 在 一 个 catch 
子 句 中 处 理 该 异常 ， 或 者 将 它 传播 出 去 。 因 此 ， 方 法 中 声明 要 抛 出 的 每 个 受 检 的 异常 ， 都 是 
对 API 用 户 的 一 种 潜在 指示 : 与 异常 相关 联 的 条 件 是 调用 这 个 方法 的 一 种 可 能 的 结果 。 


API 的 设计 者 让 API 用 户 面 对 受 检 的 异常 ， 以 此 强制 用 户 从 这 个 异常 条 件 中 恢复 。 用 户 可 
以 忽视 这 样 的 强制 要 求 ， 只 需 捕 获 异 常 并 忽略 即 可 ， 但 这 往往 不 是 个 好 办 法 ( 见 第 65 条 )。 


有 两 种 未 受 检 的 可 抛 出 结构 : 运行 时 异常 和 错误 。 在 行为 上 两 者 是 等 同 的 : 它们 都 是 不 需 
要 也 不 应 该 被 捕获 的 可 抛 出 结构 。 如 果 程 序 抛 出 未 受 检 的 异常 或 者 错误 ， 往 往 就 属于 不 可 恢 
复 的 情形 ， 继 续 执行 下 去 有 害 无 益 。 如 果 程 序 没 有 捕捉 到 这 样 的 可 抛 出 结构 ， 将 会 导致 当前 
线程 停止 (halt)， 并 出 现 适当 的 错误 消息 。 


用 运行 时 异常 来 表明 编程 错误 。 大 多 数 的 运行 时 异常 都 表示 前 提 违 例 (precondition 
violation)。 所 谓 前 提 违 例 是 指 API 的 客户 没有 遵守 API 规 范 建立 的 约定 。 例 如 ， 数 组 访问 的 约 
定 指 明了 数组 的 下 标 值 必 须 在 零 和 数组 长 度 减 1 之 间 。ArrayIndexOutOfBoundsException 表 明 
这 个 前 提 被 违反 了 。 


虽然 JILS (Java 语 言 规 范 ) 并 没有 要 求 ， 但 是 按照 惯例 ， 错 误 往往 被 JVM 保 留用 于 表示 资 
源 不 足 、 约 束 失败 ， 或 者 其 他 使 程序 无 法 继续 执行 的 条 件 。 由 于 这 已 经 是 个 几乎 被 普遍 接受 
的 惯例 ， 因 此 最 好 不 要 再 实现 任何 新 的 Error 子 类 。 因 此 ， 你 实现 的 所 有 未 受 检 的 抛 出 结构 都 
应 该 是 RuntimeException 的 子 类 (直接 的 或 者 间接 的 ) 。 


要 想 定 义 一 个 抛 出 结构 ， 它 不 是 Exception、RuntimeException 或 Error 的 子 类 ， 这 也 是 可 
能 的 。JLS 并 没有 直接 规定 这 样 的 抛 出 结构 ， 而 是 隐 式 地 指定 了 : 从 行为 意义 上 讲 它们 等 同 于 
普通 的 受 检 异 常 ( 即 Exception 的 子 类 ， 但 不 是 RuntimeException 的 子 类 )。 那 么 ， 什 么 时 候 应 
page peta TR 总 之 ， 永 远 也 不 会 用 到 。 它 与 普通 的 受 检 异 常 相 比 没有 任何 益处 ， 

会 困扰 API 的 用 户 。 . 


总 而 言 之 ， 对 于 可 恢复 的 情况 ， 使 用 受 检 的 异常 ， 对 于 程序 错误 ， 则 使 用 运行 时 异常 。 当 
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然 ， 情 况 并 不 总 是 那么 黑白 分 明 。 例 如 ， 考 虑 资源 枯竭 的 情形 ， 这 可 能 是 由 于 程序 错误 而 引 
起 的 ， 比 如 分 配 了 一 块 不 合理 的 过 大 的 数组 ， 也 可 能 确实 是 由 于 资源 不 足 而 引起 。 如 果 资 源 
枯竭 是 由 于 临时 的 短缺 ， 或 是 临时 需求 太 大 所 造成 的 ， 这 种 情况 可 能 就 是 可 恢复 的 。API 设 计 
者 需要 判断 这 样 的 资源 枯竭 是 否 允 许 恢复 。 如 果 你 相信 一 种 情况 可 能 允许 恢复 ， 就 使 用 受 检 
:的 异常 ， 如 果 不 是 ， 则 使 用 运行 时 异常 。 如 果 不 清楚 是 否 有 可 能 恢复 ， 最 好 使 用 未 受 检 的 异 
常 ， 原 因 请 参见 第 59 条 的 讨论 。 


API 的 设计 者 往往 会 忘记 ， 异常 也 是 个 完全 意义 上 的 对 象 ， 可 以 在 它 上 面 定义 任意 的 方法 。 
这 些 方 法 的 主要 用 途 是 为 捕获 异常 的 代码 而 提供 额外 的 信息 ， 特 别 是 关于 引发 这 个 异常 条 件 
的 信息 。 如 果 没有 这 样 的 方法 ， 程 序 员 必须 要 懂得 如 何 解析 “该 异常 的 字符 串 表 示 法 ”， 以 便 
获得 这 些 额外 信息 。 这 是 极为 不 好 的 做 法 〈 见 第 10 条 ) 。 类 很 少 会 指定 它们 的 字符 串 表 示 法 中 
的 细节 ， 因 此 ， 不 同 的 实现 ， 不 同 的 版 本 ， 字 符 串 表示 法 会 大 相 径 庭 。 因 此 ,“ 解 析 异 常 的 字 
符 串 表示 法 ”的 代码 可 能 是 不 可 移植 的 ， 也 是 非常 脆弱 的 。 


因为 受 检 的 异常 往往 指明 了 可 恢复 的 条 件 ， 所 以 ， 对 于 这 样 的 异常 ， 提 供 一 些 辅助 方法 万 
其 重要 ， 通 过 这 些 方 法 ， 调 用 者 可 以 获得 一 些 有 助 于 恢复 的 信息 。 例 如 ， 假 设 因为 用 户 没有 
储存 足够 数量 的 钱 ， 他 企图 在 一 个 收费 电话 上 进行 呼叫 就 会 失败 ， 于 是 抛 出 受 检 的 异常 。 这 
个 异常 应 该 提供 一 个 访问 方法 ， 以 便 允 许 客户 查询 所 缺 的 费用 金额 ， 从 而 可 以 将 这 个 数值 传 
递 给 电话 用 户 。 





受 检 的 异常 是 Java 程 序 设计 语言 的 一 项 很 好 的 特性 。 与 返回 代码 不 同 ， 它 们 强迫 程序 员 处 
理 异 常 的 条 件 ， 大 大 增强 了 可 靠 性 。 也 就 是 说 ， 过 分 使 用 受 检 的 异常 会 使 API 使 用 起 来 非常 不 ， 
方便 。 如 果 方 法 抛 出 一 个 或 者 多 个 受 检 的 异常 ， 调 用 该 方法 的 代码 就 必须 在 一 个 或 者 多 个 
catch 块 中 处 理 这 些 异 常 ， 或 者 它 必 须 声 明 它 抛 出 这 些 异 常 ， 并 让 它们 传播 出 去 。 无 论 哪 种 方 
法 ， 都 给 程序 员 增添 了 不 可 忽视 的 负担 。 


如 果 正 确 地 使 用 API 并 不 能 阻止 这 种 异常 条 件 的 产生 ， 并 且 一 旦 产生 异常 ， 使 用 API 的 程 


序 员 可 以 立即 采取 有 用 的 动作 ， 这 种 负担 就 被 认为 是 正当 的 。 除 非 这 两 个 条 件 都 成 立 ， 否 则 


更 适合 于 使 用 未 受 检 的 异常 。 作 为 一 个 “ 石 艺 ” 测 试 9 ， 你 可 以 试 着 问 自己 : 程序 员 将 如 何 处 
理 该 异常 。 下 面 的 做 法 是 最 好 的 吗 ? 


} catch(TheCheckedException e) { 
throw new AssertionError(); // Can't happen! 
} 


下 面 这 种 做 法 如 何 ? 


} catch(TheCheckedException e) { 

e.printStackTrace(); // Oh well, we lose. 
System.exit(1); 

} - 

如 果 使 用 API 的 程序 员 无 法 做 得 比 这 更 好 ， 那 么 未 受 检 的 异常 可 能 更 为 合适 。 这 种 例子 就 
是 CloneNotSupportedException。 它 是 被 Object.clone 抛 出 来 的 ， 而 Object.clone 应 该 只 是 在 实 
现 了 Cloneable 的 对 象 上 才 可 以 被 调用 ( 见 第 11 条 )。 在 实践 中 ，catch 块 几乎 总 是 具有 断言 
(assertion) 失败 的 特征 。 异 常 受 检 的 本 质 并 没有 为 程序 员 提 供 任何 好 处 ， 它 反而 需要 付出 努 
力 ， 还 使 程序 更 为 复杂 。 : 


被 一 个 方法 单独 抛 出 的 受 检 异 常 ， 会 给 程序 员 带 来 非常 高 的 额外 负担 。 如 果 这 个 方法 还 有 
其 他 的 受 检 异 常 ， 它 被 调用 的 时 候 一 定 已 经 出 现在 一 个 try 块 中 ， 所 以 这 个 异常 只 需要 另外 一 
个 catch 块 。 如 果 方 法 只 抛 出 单个 受 检 的 异常 ， 仅 仅 一 个 异常 就 会 导致 该 方法 不 得 不 外 于 try 块 
中 。 在 这 些 情况 下 ， 应 该 问 自己 ， 是 否 有 别 的 途径 来 避免 使 用 受 检 的 异常 。 


“把 受 检 的 异常 变 成 未 受 检 的 异常 ”的 一 种 方法 是 ， 把 这 个 抛 出 异常 的 方法 分 成 两 个 方 . 
法 ， 其 中 第 一 个 方法 返回 一 个 boolean， 表 明 是 否 应 该 抛 出 异常 。 这 种 API 重 构 ， 把 下 面 的 调 
用 序列 : 


O 石 营 测 试 指 简单 而 具有 决定 性 的 测试 。 一 一 编辑 注 
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// Invocation with checked exception 
try { 

obj.action(args); 
} catch(TheCheckedException e) { 

// Handle exceptional condition 


} 


重 构 为 : 


// Invocation with state-testing method and unchecked exception 
if (obj.actionPermitted(args)) { 

obj.action(args); 
} else { 

// Handle exceptional condition 


} 


这 种 重 构 并 不 总 是 恰当 的 ， 但 是 ， 凡 是 在 恰当 的 地 方 ， 它 都 会 使 API 用 起 来 更 加 舒服 。 虽 
然后 者 的 调用 序列 没有 前 者 的 漂亮 ， 但 是 这 样 得 到 的 API 更 加 灵活 。 如 果 程 序 员 知道 调用 将 会 
成 功 ， 或 者 不 介意 由 于 调用 失败 而 导致 的 线程 终止 ， 这 种 重 构 还 允许 以 下 这 个 更 为 简单 的 调 
用 形式 : 


obj.action(args); 


如 果 你 怀疑 这 个 简单 的 调用 序列 是 否 合乎 要 求 ， 这 个 API 重 构 可 能 就 是 恰当 的 。 这 种 重 构 
之 后 的 API 在 本 质 上 等 同 于 第 57 条 中 的 “状态 测试 方法 ” ， 并 且 ， 同 样 的 告诫 依然 适用 : 如 果 
对 象 将 在 缺少 外 部 同步 的 情况 下 被 并 发 访问 ， 或 者 可 被 外 界 改变 状态 ， 这 种 重 构 就 是 不 恰当 
的 ， 因 为 在 actionPermitted 和 action 这 两 个 调用 的 时 间 间 隔 之 中 ， 对 象 的 状态 有 可 能 会 发 生变 
化 。 如 果 单 独 的 actionPermitted 方 法 必须 重复 action 方 法 的 工作 ， 出 于 性 能 的 考虑 ， 这 种 API 
重 构 就 不 值得 去 做 。 





专家 级 程序 员 与 缺乏 经 验 的 程序 员 一 个 最 主要 的 区 别 在 于 ， 专 家 追求 并 且 通 常 也 能 够 实现 
高 度 的 代码 重用 。 代 码 重 用 是 值得 提倡 的 ， 这 是 一 条 通用 的 规则 ， 异 常 也 不 例外 。Java 平 台 类 
库 提供 了 一 组 基本 的 未 受 检 的 异常 ， 它 们 满足 了 绝 大 多 数 API 的 异常 抛 出 需要 。 本 条 目 中 ,我 
们 将 讨论 这 些 常 见 的 可 重用 异常 。 


重用 现 有 的 异常 有 多 方面 的 好 处 。 其 中 最 主要 的 好 处 是 , 它 使 你 的 API 更 加 易于 学 习 和 使 用 ， 
因为 它 与 程序 员 已 经 熟悉 的 习惯 用 法 是 一 致 的 。 第 二 个 好 处 是 ， 对 于 用 到 这 些 API 的 程序 而 言 ， 
它们 的 可 读 性 会 更 好 ， 因 为 它们 不 会 出 现 很 多 程序 员 不 熟悉 的 异常 。 最 后 (也 是 最 不 重要 的 ) 
一 点 是 ， 异 常 类 越 少 ， 意 味 着 内 存 印 迹 (footprint) 就 越 小 ， 装 载 这 些 类 的 时 间 开 销 也 越 少 。 


最 经 常 被 重用 的 异常 是 lllegalArgumentException。 当 调用 者 传递 的 参数 值 不 合适 的 时 候 ， 
往往 就 会 抛 出 这 个 异常 。 例 如 ， 假 设 一 个 参数 代表 了 “ 某 个 动作 的 重复 次 数 ”"， 如 果 程 序 员 给 
这 个 参数 传递 了 一 个 负数 ， 就 会 抛 出 这 个 异常 。 - 


另 一 个 经 常 被 重用 的 异常 是 IllegalStateException。 如 果 因 为 接收 对 象 的 状态 而 使 调用 非 
法 ， 通常 就 会 抛 出 这 个 异常 。 例 如 ， 如 果 在 某 个 对 象 被 正确 地 初始 化 之 前 ， 调 用 者 就 企图 使 
用 这 个 对 象 ， 就 会 抛 出 这 个 异常 。 


可 以 这 么 说 ， 所 有 错误 的 方法 调用 都 可 以 被 归结 为 非法 参数 或 者 非法 状态 ， 但 是 ， 其 他 还 
有 一 些 标准 异常 也 被 用 于 某 些 特定 情况 下 的 非法 参数 和 非法 状态 。 如 果 调 用 者 在 某 个 不 允许 
null 值 的 参数 中 传递 了 null， 习 惯 的 做 法 就 是 抛 出 NullPointerException， 而 不 是 TllegalArgument- 
Exception。 同 样 地 ， 如 果 调 用 者 在 表示 序列 下 标的 参数 中 传递 了 越界 的 值 ， 应 该 抛 出 的 就 是 
IndexOutOfBoundsException, ， 而 不 是 IllegalArgumentException 。 


另 一 个 值得 了 解 的 通用 异常 是 ConcurrentModificationException。 如 果 一 个 对 象 被 设计 为 
专用 于 单线 程 或 者 与 外 部 同步 机 制 配 合 使 用 ， 一旦 发 现 它 正在 (或 已 经 ) 被 并 发 地 修改 ， 就 
应 该 抛 出 这 个 异常。 


最 后 一 个 值得 注意 的 通用 异常 是 UnsupportedOperationException。 如 果 对 象 不 支持 所 请 求 
的 操作 ， 就 会 抛 出 这 个 异常 。 与 本 条 目 中 讨论 的 其 他 异常 相 比 ， 它 很 少 用 到 ， 因 为 绝 大 多 数 
对 象 都 会 支持 它们 实现 的 所 有 方法 。 如 果 接 口 的 具体 实现 没有 实现 该 接口 所 定义 的 一 个 或 者 
多 个 可 选 操作 ， 它 就 可 以 使 用 这 个 异常 。 例 如 ， 对 于 只 支持 追加 操作 的 List 实 现 ， 如 果 有 人 试 
图 从 列表 中 删除 元 素 ， 它 就 会 抛 出 这 个 异常 。 


表 9-1 概 括 了 最 常见 的 可 重用 异常 。 
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表 9-1 常用 的 异常 
i 
异 - R 使 用 场合 
IllegalArgumentException 非 null 的 参数 值 不 正确 
lllegalStateException 对 于 方法 调用 而 言 ， 对 象 状态 不 合适 
NullPointerException 在 禁止 使 用 null 的 情况 下 参数 值 为 null 
IndexOutOfBoundsException 下 标 参 数值 越界 
ConcurrentModificationException 在 禁止 并 发 修改 的 情况 下 ,检测 到 对 象 的 并 发 修改 
UnsupportedOperationException 对 象 不 支持 用 户 请 求 的 方法 


虽然 它们 是 Java 平 台 类 库 中 迄今 为 止 最 常 被 重用 的 异常 但是， 在 条 件 许 可 的 情况 下 ， 其 
他 的 异常 也 可 以 被 重用 。 例 如 ， 如 果 要 实现 诸如 复数 或 者 有 理 数 之 类 的 算术 对 象 ， 也 可 以 重 
用 ArithmeticException 和 NumberFormatException 。 如 果 某 个 异常 能 够 满足 你 的 需要 ， 就 不 要 
犹 称 ， 使 用 就 是 ， 不 过 ， 一 定 要 确保 抛 出 异常 的 条 件 与 该 异常 的 文档 中 描述 的 条 件 一 致 。 这 种 
重用 必须 建立 在 语义 的 基础 上 ， 而 不 是 建立 在 名 称 的 基础 之 上 。 而 且 ， 如 果 希 望 稍微 增加 更 多 
的 失败 一 捕获 (failure-capture) 信息 ( 见 第 63 条 )， 可 以 放心 地 把 现 有 的 异常 进行 子 类 化 。 


最 后 ， 一 定 要 清楚 ， 选 择 重用 哪个 异常 并 不 总 是 那么 精确 ， 因 为 上 表 中 的 “使 用 场合 ”并 
不 是 相互 排斥 的 。 例如， 考虑 表示 一 副 纸 牌 的 对 象 。 假 设 有 个 处 理发 牌 操作 的 方法 ， 它 的 参 
数 是 发 一 手 牌 的 纸牌 张 数 。 假 设 调用 者 在 这 个 参数 中 传递 的 值 大 于 整 副 纸牌 的 剩余 张 数 。 这 
种 情形 既 可 以 被 解释 为 IllegalArgumentException (handSize 参 数 的 值 太 大 ) ， 也 可 以 被 解释 为 
IllegalStateException (相对 于 客户 的 请 求 而 言 ， 纸 牌 对 象 包含 的 纸牌 太 少 ) 。 在 这 个 例子 中 ， 
感觉 IllegalArgumentException 要 好 一 些 ， 不 过 ， 这 里 并 没有 严格 的 规则 。 
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如 果 方 法 抛 出 的 异常 与 它 所 执行 的 任务 没有 明显 的 联系 ， 这 种 情形 将 会 使 人 不 知 所 措 。 当 
方法 传递 由 低层 抽象 抛 出 的 异常 时 ， 往 往 会 发 生 这 种 情况 。 除 了 使 人 感到 困惑 之 外 ， 这 也 让 
实现 细节 污染 了 更 高 层 的 API。 如 果 高 层 的 实现 在 后 续 的 发 行 版 本 中 发 生 了 变化 ， 它 所 抛 出 的 
异常 也 可 能 会 跟着 发 生变 化 ， 从 而 潜在 地 破坏 现 有 的 客户 端 程序 。 


为 了 避免 这 个 问题 ， 更 高 层 的 实现 应 该 捕获 低层 的 异常 ， 同 时 抛 出 可 以 按照 高 层 抽 象 进行 
解释 的 异常 。 这 种 做 法 被 称 为 异常 转译 (exception translation), ， 如 下 所 示 


// Exception Translation 
try { 


// Use lower-level abstraction to do our bidding 


} catch(LowerLevelException e) { 
throw new HigherLevelException(...); 


下 面 的 异常 转译 例子 取 自 于 AbstractSequentialList 类 ， 该 类 是 List 接 口 的 一 个 骨架 实现 


(skeletal implementation) ( 见 第 18 条 )。 在 这 个 例子 中 ， 按 照 List<E> 接 口中 get 方 法 的 规范 
要 求 ， 异 常 转译 是 必需 的 : ' 


[tr 

* Returns the element at the specified position in this list. 
* @throws IndexOutOfBoundsException if the index is out of range 
* ({@code index < 0 || index >= size()}). 

/ 


* 
public E get(int index) { 
ListIterator<E> i = listIterator(index); 
try { 
return i.nextQ); 
} catch(NoSuchElementException e) { 
: throw new IndexOutOfBoundsException("Index: ”+ index); 


} 


一 种 特殊 的 异常 转译 形式 称 为 异常 链 (exception chaining) ， 如 果 低层 的 异常 对 于 调试 导 
致 高 层 异常 的 问题 非常 有 帮助 ， 使 用 异常 链 就 很 合适 。 低 层 的 异常 (原因 ) 被 传 到 高 层 的 异 
常 ， 高 层 的 异常 提供 访问 方法 (Throwable.getCause) 来 获得 低层 的 异常 : 

// Exception Chaining 

ee . // Use lower-level abstraction to do our bidding 


} catch (LowerLevelException cause) { 
throw new HigherLevelException(cause) ; 
} 


高 层 异常 的 构造 器 将 原因 传 到 支持 链 (chaining-aware) 的 超级 构造 器 ， 因 此 它 最 终 将 被 
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传 给 Throwable 的 其 中 一 个 运行 异常 链 的 构造 器 ， 例 如 Throwable (Throwable) : 


// Exception with chaining-aware constructor 
class HigherLevelException extends Exception { 
HigherLevelException(Throwable cause) { 

super(cause); 


} 


大 多 数 标准 的 异常 都 有 支持 链 的 构造 器 。 对 于 没有 支持 链 的 异常 ， 可 以 利用 Throwable 的 
initCause 方 法 设置 原因 。 异 常 链 不 仅 让 你 可 以 通过 程序 (用 getCause) 访问 原因 ， 它 还 可 以 
将 原因 的 堆栈 轨迹 集成 到 更 高 层 的 异常 中 。 


尽管 异常 转译 与 不 加 选择 地 从 低层 传递 异常 的 做 法 相 比 有 所 改进 ， 但 是 它 也 不 能 被 滥用 。 
如 有 可 能 ， 处 理 来 自 低层 异常 的 最 好 做 法 是 ， 在 调用 低层 方法 之 前 确保 它们 会 成 功 执 行 ， 从 
而 避免 它们 抛 出 异常 。 有 了 时候， 可 以 在 给 低层 传递 参数 之 前 ， 检 查 更 高 层 方法 的 参数 的 有 效 
性 ， 从 而 避免 低层 方法 抛 出 异常 。 ’ 


如 果 无 法 避免 低层 异常 ， 次 选 方案 是 ， 让 更 高 层 来 悄悄 地 绕 开 这 些 异常 ， 从 而 将 高 层 方法 
的 调用 者 与 低层 的 问题 隔离 开 来 。 在 这 种 情况 下 ， 可 以 用 某 种 适当 的 记录 机 制 (如 
java.util.logging) 将 异常 记录 下 来 。 这 样 有 助 于 管理 员 调查 问题 ， 同 时 又 将 客户 端 代码 和 最 
终 用 户 与 问题 隔离 开 来 。 


总 而 言 之 ， 如 果 不 能 阻止 或 者 处 理 来 自 更 低层 的 异常 ， 一 般 的 做 法 是 使 用 异常 转译 ， 除 非 
低层 方法 碰巧 可 以 保证 它 抛 出 的 所 有 异常 对 高 层 也 合适 才 可 以 将 异常 从 低层 传播 到 高 层 。 异 
常 链 对 高 层 和 低层 异常 都 提供 了 最 佳 的 功能 : 它 允 许 抛 出 适当 的 高 层 异 常 ， 同 时 又 能 捕获 底 
层 的 原因 进行 失败 分 析 ( 见 第 63 条 )。 
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描述 一 个 方法 所 抛 出 的 异常 ， 是 正确 使 用 这 个 方法 时 所 需 文档 的 重要 组 成 部 分 。 因 此 ， 花 
点 时 间 仔 细 地 为 每 个 方法 抛 出 的 异常 建立 文档 是 特别 重要 的 。 


始终 要 单独 地 声明 受 检 的 异常 ， 并 且 利用 Javadoc 的 @throws 标 记 ， 准 确 地 记录 下 抛 出 每 
个 异常 的 条 件 。 如 果 一 个 方法 可 能 抛 出 多 个 异常 类 ， 则 不 要 使 用 “快捷 方式 ”声明 它 会 抛 出 
这 些 异 常 类 的 某 个 超 类 。 永 远 不 要 声明 一 个 方法 “throws Exception”， 或 者 更 精 糕 的 是 声明 
È “throws Throwable”， 这 是 非常 极端 的 例子 。 这 样 的 声明 不 仅 没有 为 程序 员 提供 关于 “这 
个 方法 能 够 抛 出 哪些 异常 ”的 任何 指导 信息 ， 而 且 大 大 地 妨碍 了 该 方法 的 使 用 ， 因 为 它 实际 
上 掩盖 了 该 方法 在 同样 的 执行 环境 下 可 能 抛 出 的 任何 其 他 异常 。 


虽然 Java 语 言 本 身 并 不 要 求 程序 员 为 一 个 方法 声明 它 可 能 会 抛 出 的 未 受 检 异 常 ， 但 是 ， 如 
同 受 检 异 常 一 样 ， 仔 细 地 为 它们 建立 文档 是 非常 明智 的 。 未 受 检 的 异常 通常 代表 编程 上 的 错 
误 ( 见 第 58 条 )， 让 程序 员 了 解 所 有 这 些 错 误 都 有 助 于 帮助 他 们 避免 犯 这 样 的 错误 。 对 于 方法 
可 能 抛 出 的 未 受 检 异 常 ， 如 果 将 这 些 异 常 信息 很 好 地 组 织 成 列表 文档 ， 就 可 以 有 效 地 描述 出 
这 个 方法 被 成 功 执行 的 前 提 条 件 (precondition)。 每 个 方法 的 文档 应 该 描述 它 的 前 提 条 件 ， 
这 是 很 重要 的 ， 在 文档 中 记录 下 未 受 检 的 异常 是 满足 前 提 条 件 的 最 佳 做 法 。 


对 于 接口 中 的 方法 ， 在 文档 中 记录 下 它 可 能 抛 出 的 未 受 检 异 常 显得 尤为 重要 。 这 份 文档 构 
成 了 该 接口 的 通用 约定 (general contract) 的 一 部 分 ， 它 指定 了 该 接口 的 多 个 实现 必须 遵循 
的 公共 行为 。 


使 用 Javadoc 的 @throws 标 签 记 录 下 一 个 方法 可 能 抛 出 的 每 个 未 受 检 异 常 ， 但 是 不 要 使 用 
throws 关 键 字 将 未 受 检 的 异常 包含 在 方法 的 声明 中 。 使 用 API 的 程序 员 必 须知 道 哪些 异常 是 需 
要 受 检 的 ， 哪 些 是 不 需要 受 检 的 ， 这 很 重要 ， 因 为 这 两 种 情况 下 他 们 的 责任 是 不 同 的 。 当 和 缺 
少 由 throws 声 明 产 生 的 方法 标 头 时 ， 由 Javadoc 的 @throws 标 签 所 产生 的 文档 就 会 提供 明显 的 
提示 信息 ， 以 帮助 程序 员 区 分 受 检 的 异常 和 未 受 检 的 异常 。 


应 该 注意 到 ， 为 每 个 方法 可 能 抛 出 的 所 有 未 受 检 异 常 建 立 文档 是 很 理想 的 ， 但 是 在 实践 中 
并 非 总 能 做 到 这 一 点 。 当 类 被 修订 之 后 ， 如 果 有 个 导出 方法 被 修改 了 ， 它 将 会 抛 出 额外 的 未 
受 检 异 常 ， 这 不 算 者 反 源 代码 或 者 二 进 制 兼容 性 。 假 设 一 个 类 调用 了 另 一 个 独立 类 中 的 方法 。 
第 一 个 类 的 编写 者 可 能 会 为 每 个 方法 抛 出 的 未 受 检 异 常 仔细 地 建立 文档 ， 但 是 ， 如 果 第 二 个 
类 被 修订 了 ， 抛 出 了 额外 的 未 受 检 异 常 ， 很 有 可 能 第 一 个 类 ( 它 并 没有 被 修订 ) 就 会 把 新 的 
未 受 检 异 常 传播 出 去 ， 尽 管 它 并 没有 声明 这 些 异常 。 


如 果 一 个 类 中 的 许多 方法 出 于 同样 的 原因 而 抛 出 同一 个 异常 ， 在 该 类 的 文档 注释 中 对 这 个 
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异常 建立 文档 ， 这 是 可 以 接受 的 ， 而 不 是 为 每 个 方法 单独 建立 文档 。 一 个 常见 的 例子 是 
NullPointerException。 如 果 类 的 文档 注释 中 有 这 样 的 描述 :“(All methods in this class throw 
a NullPointerException if a null object reference is passed in any parameter) 如 果 null 对 象 引 
用 被 传递 到 任何 一 个 参数 中 ， 这 个 类 中 的 所 有 方法 都 会 抛 出 NullPointerException”， 或 者 有 其 
他 类 似 的 语句 ， 这 是 可 以 的 。 


总 而 言 之 ， 要 为 你 编写 的 每 个 方法 所 能 抛 出 的 每 个 异常 建立 文档 。 对 于 未 受 检 和 受 检 的 异 
常 ， 以 及 对 于 抽象 的 和 具体 的 方法 也 都 一 样 。 要 为 每 个 受 检 异 常 提供 单独 的 throws 子 名 ， 不 要 
为 未 受 检 的 异常 提供 throws 子 句 。 如 果 没 有 为 可 以 抛 出 的 异常 建立 文档 ， 其 他 人 就 很 难 或 者 根 
本 不 可 能 有 效 地 使 用 你 的 类 和 接口 。 
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当 程 序 由 于 未 被 捕获 的 异常 而 失败 的 时 候 ， 系 统 会 自动 地 打印 出 该 异常 的 堆栈 轨迹 。 在 堆 
栈 轨迹 中 包含 该 异常 的 字符 串 表 示 法 (string representation), ， 即 它 的 toString 方 法 的 调用 结 
果 。 它 通常 包含 该 异常 的 类 名 ， 紧 随 其 后 的 是 细节 消息 (detail message)。 通 常 ， 这 只 是 程 
序 员 或 者 域 服务 人 员 (field service personnel， 指 检查 软件 失败 的 人 ) 在 调查 软件 失败 原因 时 
必须 检查 的 信息 。 如 果 失 败 的 情形 不 容易 重 现 ， 要 想 获得 更 多 的 信息 会 非常 困难 ， 甚至 是 不 
可 能 的 。 因 此 ， 异常 类 型 的 toString 方 法 应 该 尽 可 能 多 地 返回 有 关 失败 原因 的 信息 ， 这 一 点 特 
别 重 要 。 换 名 话说， 异常 的 细节 消息 应 该 捕获 住 失败 ， 便 于 以 后 分 析 。 


为 了 捕获 失败 ， 异 常 的 细节 信息 应 该 包含 所 有 “对 该 异常 有 贡献 ”的 参数 和 域 的 值 。 例 如 ， 
IndexOutOfBoundsException 异 常 的 细节 消息 应 该 包含 下 界 、 上 界 以 及 没有 落 在 界 内 的 下 标 值 。 
该 细节 消息 提供 了 许多 关于 失败 的 信息 。 这 三 个 值 中 任何 一 个 或 者 全 部 都 有 可 能 是 错 的 。 实 
慰 的 下 标 值 可 能 小 于 下 界 或 等 于 上 界 (“越界 错误 ”)， 或 者 它 可 能 是 个 无 效 值 ， 太 小 或 太 大 。 
下 界 也 有 可 能 大 于 上 界 (严重 违反 内 部 约束 条 件 的 一 种 情况 )。 每 一 种 情形 都 代表 了 不 同 的 问 
题 ， 如 果 程 序 员 知道 应 该 去 查找 哪 种 错误 ， 就 可 以 极 大 地 加 速 诊断 过 程 。 


虽然 在 异常 的 细节 消息 中 包含 所 有 相关 的 “ 硬 数 据 (hard data) ”是 非常 重要 的 ， 但 是 包 
含 大 量 的 描述 信息 往往 没有 什么 意义 。 堆 栈 轨迹 的 用 途 是 与 源 文件 结合 起 来 进行 分 析 ， 它 通 
常 包含 抛 出 该 异常 的 确切 文件 和 行 数 ， 以 及 堆栈 中 所 有 其 他 方法 调用 所 在 的 文件 和 行 数 。 关 
于 失败 的 元 长 描述 信息 通常 是 不 必要 的 ， 这 些 信 息 可 以 通过 阅读 源 代码 而 获得 。 


异常 的 细节 消息 不 应 该 与 “用 户 层次 的 错误 消息 ”混为一谈 ， 后 者 对 于 最 终 用 户 而 言 必须 
是 可 理解 的 。 与 用 户 层次 的 错误 消息 不 同 ， 异 常 的 字符 串 表示 法 主要 是 让 程序 员 或 者 域 服务 
人 员 用 来 分 析 失 败 的 原因 。 因 此 ， 信 息 的 内 容 比 可 理解 性 要 重要 得 多 。 


为 了 确保 在 异常 的 细节 消息 中 包含 足够 的 能 捕获 失败 的 信息 ， 一 种 办 法 是 在 异常 的 构造 器 
而 不 是 字符 串 细 节 消 息 中 引入 这 些 人 信息。 然后， 有 了 这 些 信 息 ， 只 要 把 它们 放 到 消息 描述 中 ， 
就 可 以 自动 产生 细节 消息 。 例 如 ，IndexOutOfBoundsException 并 不 是 有 个 String 构 造 器 ， 而 
是 有 个 这 样 的 构造 器 : 

< Cònstrüdt an IndexOutOfBoundsException. 

; @param lowerBound the lowest legal index value. 

+ @param upperBound the highest legal index value plus one. 

+ @param index the actual index value. 

K-A IndexOutOfBoundsException(int lowerBound, int upperBound, 


int index) { 
// Generate a detail message that captures the failure 
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super("Lower bound: " + lowerBound + 
", Upper bound: ”+ upperBound + 
本 + index); 


// Save failure information for programmatic access 
this. lowerBound = lowerBound; 
this.upperBound = upperBound; 
, this.index = index; 
} 
遗憾 的 是 ，Java 平 台 类 库 并 没有 广泛 地 使 用 这 种 做 法 , 但 是 ， 这 种 做 法 仍然 值得 大 力 推荐 。 
它 使 程序 员 更 加 易于 抛 出 异常 以 捕获 失败 。 实 际 上 ， 这 种 做 法 使 程序 员 不 想 捕获 失败 都 难 ! 
这 种 做 法 可 以 有 效 地 把 代码 集中 起 来 放 在 异常 类 中 ， 由 这 些 代码 对 异常 类 自身 中 的 异常 产生 


高 质量 的 细节 消息 ， 而 不 是 要 求 类 的 每 个 用 户 都 多 余地 产生 细节 消息 。 


正如 第 58 条 中 所 建议 的 ， 为 异常 的 “失败 捕获 ”信息 提供 一 些 访 问 方法 是 合适 的 (在 上 
述 例 子 中 的 lowerBound、upperBound 和 index 方 法 ) 提供 一 些 访问 方法 是 合适 的 。 提 供 这 样 的 
访问 方法 对 于 受 检 的 异常 ， 比 对 于 未 受 检 的 异常 更 为 重要 ， 因 为 失败 一 一 捕获 信息 对 于 从 失败 
中 恢复 是 非常 有 用 的 。 程 序 员 希 望 通过 程序 的 手段 来 访问 未 受 检 蜡 常 的 细节 ， 这 很 少见 OUR 
管 也 是 可 以 想像 得 到 的 ) 。 然 而 ， 即 使 对 于 未 受 检 的 异常 ， 作 为 一 般 原则 提供 这 些 访问 方法 也 
是 明智 的 〈 见 第 44 页 中 的 第 10 条 ) 。 
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当 对 象 抛 出 异常 之 后 ， 通 常 我 们 期 望 这 个 对 象 仍然 保持 在 二 种 定义 良好 的 可 用 状态 之 中 ， 
即使 失败 是 发 生 在 执行 某 个 操作 的 过 程 中 间 。 对 于 受 检 的 异常 而 言 ， 这 尤为 重要 ， 因 为 调用 
者 期 望 能 从 这 种 异常 中 进行 恢复 。 一 般 而 言 ， 失 败 的 方法 调用 应 该 使 对 象 保 持 在 被 调用 之 前 
的 状态 。 具 有 这 种 属性 的 方法 被 称 为 具有 失败 原子 性 (failure atomic), 


有 几 种 途径 可 以 实现 这 种 效果 。 最 简单 的 办 法 莫 过 于 设计 一 个 不 可 变 的 对 象 ( 见 第 15 条 ) 。 
如 果 对 象 是 不 可 变 的 ， 失 败 原 子 性 就 是 显然 的 。 如 果 一 个 操作 失败 了 ， 它 可 能 会 阻止 创建 新 
的 对 象 ， 但 是 永远 也 不 会 使 已 有 的 对 象 保持 在 不 一 致 的 状态 之 中 ， 因 为 当 每 个 对 象 被 创建 之 
后 它 就 处 于 一 致 的 状态 之 中 ， 以 后 也 不 会 再 发 生变 化 。 


对 于 在 可 变 对 象 上 执行 操作 的 方法 ， 获 得 失败 原子 性 最 常见 的 办 法 是 ， 在 执行 操作 之 前 检 
查 参数 的 有 效 性 〈 见 第 38 条 )。 这 可 以 使 得 在 对 象 的 状态 被 修改 之 前 ， 先 抛 出 适当 的 异常 。 例 
如 ， 考 虑 第 6 条 中 的 Stack.pop 方 法 : 

public Object pop() { 

if (size == @) 
throw new EmptyStackException() ; 
Object result = elements[--size]; 
elements[size] = null; // Eliminate obsolete reference 
return result; 

} 

如 果 取 消 对 初始 大 小 (size) 的 检查 ， 当 这 个 方法 企图 从 一 个 空 栈 中 弹出 元 素 时 ， 它 仍然 
会 抛 出 异常 。 然 而 ， 这 将 会 导致 size 域 保持 在 不 一 致 的 状态 (负数 ) 之 中 ， 从 而 导致 将 来 对 该 


对 象 的 任何 方法 调用 都 会 失败 。 此 外 ， 那 时 候 pop 方 法 抛 出 的 异常 也 不 适 于 抽象 ( 见 第 61 条 )。- 


一 种 类 似 的 获得 失败 原子 性 的 办 法 是 ， 调 整 计算 处 理 过 程 的 顺序 ， 使 得 任何 可 能 会 失败 的 
计算 部 分 都 在 对 象 状态 被 修改 之 前 发 生 。 如 果 对 参数 的 检查 只 有 在 执行 了 部 分 计算 之 后 才能 
进行 ， 这 种 办 法 实际 上 就 是 上 一 种 办 法 的 自然 扩展 。 例 如 ， 考 虑 TreeMap 的 情形 ， 它 的 元 素 被 
按照 某 种 特定 的 顺序 做 了 排序 。 为 了 向 TreeMap 中 添加 元 素 ， 该 元 素 的 类 型 就 必须 是 可 以 利用 
TreeMap 的 排序 准则 与 其 他 元 素 进行 比较 的 。 如 果 企 图 增加 类 型 不 正确 的 元 素 ， 在 tree 以 任何 
方式 被 修改 之 前 ， 自 然 会 导致 ClassCastException 异 常 。 


第 三 种 获得 失败 原子 性 的 办 法 远 远 没有 那么 常用 ， 做 法 是 编写 一 段 恢 复 代码 (recovery 
code)， 由 它 来 拦截 操作 过 程 中 发 生 的 失败 ， 以 及 使 对 象 回 滚 到 操作 开始 之 前 的 状态 上 。 这 种 
办 法 主要 用 于 永久 性 的 (基于 磁盘 的 (disk-based)) 数据 结构 。 


最 后 一 种 获得 失败 原子 性 的 办 法 是 ， 在 对 象 的 一 份 临时 拷贝 上 执行 操作 ， 当 操作 完成 之 后 
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再 用 临时 拷贝 中 的 结果 代替 对 象 的 内 容 。 如 果 数 据 保存 在 临时 的 数据 结构 中 ， 计 算 过 程 会 更 
加 迅速 ， 使 用 这 种 办 法 就 是 件 很 自然 的 事 。 例 如 ，Collections.sort 在 执行 排序 之 前 ， 首 先 把 它 
的 输入 列表 转 到 一 个 数组 中 ， 以 便 降 低 在 排序 的 内 循环 中 访问 元 素 所 需要 的 开销 。 这 是 出 于 
性 能 考虑 的 做 法 ， 但 是 ， 它 增加 了 一 项 优势 : 即使 排序 失败 ， 它 也 能 保证 输入 列表 保持 原样 。 


虽然 一 般 情 况 下 都 希望 实现 失败 原子 性 ， 但 并 非 总 是 可 以 做 到 。 例 如 ， 如 果 两 个 线程 企图 
在 没有 适当 的 同步 机 制 的 情况 下 ， 并 发 地 修改 同一 个 对 象 ， 这 个 对 象 就 有 可 能 被 留 在 不 一 臻 
的 状态 之 中 。 因 此 ， 在 捕获 了 ConcurrentModificationException 异 常 之 后 再 假设 对 象 仍然 是 可 
用 的 ， 这 就 是 不 正确 的 。 错 误 (相对 于 异常 ) 通常 是 不 可 恢复 的 ， 当 方法 抛 出 错误 时 ， 它 们 
不 需要 努力 保持 失败 原子 性 。 l 


即使 在 可 以 实现 失败 原子 性 的 场合 ， 它 也 并 不 总 是 人 们 所 期 望 的 。 对 于 某 些 操作 ， 它 会 显 
著 地 增加 开销 或 者 复杂 性 。 但 一 旦 意识 到 这 个 问题 ， 实 现 失败 原子 性 往往 轻松 自如 。 


一 般 而 言 ， 作 为 方法 规范 的 一 部 分 ， 产 生 的 任何 异常 都 应 该 让 对 象 保持 在 该 方法 调用 之 前 
的 状态 。 如 果 违 反 这 条 规则 ，API 文 档 就 应 该 清楚 地 指明 对 象 将 会 处 于 什么 样 的 状态 。 遗 憾 的 
是 ， 大 量 现 有 的 API 文 档 都 未 能 做 到 这 一 点 。 





尽管 这 条 建议 看 上 去 是 显而易见 的 ， 但 是 它 却 常常 被 违反 ， 因 而 值得 再 次 提出 来 。 当 API 
的 设计 者 声明 一 个 方法 将 抛 出 某 个 异常 的 时 候 ， 他 们 等 于 正在 试图 说 明 某 些 事情 。 所 以 ， 请 
不 要 忽略 它 ! 要 忽略 一 个 异常 非常 容易 ， 只 需 将 方法 调用 通过 try 语 句 包围 起 来 ， 并 包含 一 个 
空 的 catch 块 : 


// Empty catch block ignores exception - Highly suspect! 
try { 


3 catch (SomeException e) { 

空 的 catch 块 会 使 异常 达 不 到 应 有 的 目的 ， 即 强迫 你 处 理 异 常 的 情况 。 忽 略 异 常 就 如 同 忽 
略 火 警 信号 一 样 一 一 若 把 火警 信号 器 关 掉 了 ， 当 真正 的 火灾 发 生 时 ， 就 没有 人 能 看 到 火警 信号 
了 。 或 许 你 会 侥幸 逃 过 劫难 ， 或 许 结果 将 是 灾难 性 的 。 每 当 见 到 空 的 catch 块 时 ， 应 该 警钟 长 
鸣 。 至 少 ，catch 块 也 应 该 包含 一 条 说 明 ， 解 释 为 什么 可 以 忽略 这 个 异常 。 


有 一 种 情形 可 以 忽略 异常 , 即 关闭 FileInputStream 的 时 候 。 因 为 你 还 没有 改变 文件 的 状态 ， 
因此 不 必 执 行 任何 恢复 动作 ， 并 且 已 经 从 文件 中 读 取 到 所 需要 的 信息 ， 因 此 不 必 终 止 正在 进 
行 的 操作 。 即 使 在 这 种 情况 下 ， 把 异常 记录 下 来 还 是 明智 的 做 法 ， 因 为 如 果 这 些 异常 经 常 发 
生 ， 你 就 可 以 调查 异常 的 原因 。 


本 条 目 中 的 建议 同样 适用 于 受 检 异常 和 未 受 检 的 异常 。 不 管 异常 代表 了 可 预见 的 异常 条 
件 ， 还 是 编程 错误 ， 用 空 的 catch 块 忽略 它 ， 将 会 导致 程序 在 遇 到 错误 的 情况 下 悄然 地 执行 下 
去 。 然 后 ， 有 可 能 在 将 来 的 某 个 点 上 ， 当 程序 不 能 再 容忍 与 错误 源 明 显 相关 的 问题 时 ， 它 就 
会 失败 。 正 确 地 处 理 异 常 能 够 彻底 挽回 失败 。 只 要 将 异常 传播 给 外 界 ， 至 少 会 导致 程序 迅速 
地 失败 ， 从 而 保留 了 有 助 于 调试 该 失败 条 件 的 信息 。 





线程 (Thread) 机 制 允许 同时 进行 多 个 活动 。 并 发 程序 设计 比 单线 程 程序 设计 要 困难 得 
多 ， 因 为 有 更 多 的 东西 可 能 出 错 ， 也 很 难以 重 现 失 败 。 但 是 你 无 法 避免 并 发 ， 因 为 我 们 所 做 
的 大 部 分 事情 都 需要 并 发 ， 而 且 并 发 也 是 能 否 从 多 核 的 处 理 器 中 获得 好 的 性 能 的 一 个 条 件 ， 
这 些 现在 都 是 很 平常 的 事 了 。 本 章 阐 述 的 建议 可 以 帮助 你 编写 出 清晰 、 正 确 、 文 档 组 织 良好 
的 并 发 程序 。 





第 66 条 : 同步 访问 共享 的 nm 


关键 字 synchronized 可 以 保证 在 同一 时 刻 ， 只 有 一 个 线程 可 以 执行 某 一 个 方法 ， 或 者 某 一 
个 代码 块 。 许 多 程序 员 把 同步 的 概念 仅仅 理解 为 一 种 互 斥 的 方式 ， 即 ， 当 一 个 对 象 被 一 个 线 
程 修 改 的 时 候 ， 可 以 阻止 另 一 个 线程 观察 到 对 象 内 部 不 一 致 的 状态 。 按 照 这 种 观点 ， 对 象 被 、 
创建 的 时 候 处 于 一 致 的 状态 ( 见 第 15 条 )， 当 有 方法 访问 它 的 时 候 ， 它 就 被 锁定 了 。 这 些 方法 
观察 到 对 象 的 状态 ， 并 且 可 能 会 引起 状态 转变 (state transition)， 即 把 对 象 从 一 种 一 致 的 状 
态 转换 到 另 一 种 一 致 的 状态 。 正 确 地 使 用 同步 可 以 保证 没有 任何 方法 会 看 到 对 象 处 于 不 一 致 
的 状态 中 。 


这 种 观点 是 正确 的 ， 但 是 它 并 没有 说 明 同步 的 全 部 意义 。 如 果 没 有 同步 ， 一 个 线程 的 变化 
就 不 能 被 其 他 线程 看 到 。 同 步 不 仅 可 以 阻止 一 个 线程 看 到 对 象 处 于 不 一 致 的 状态 之 中 ， 它 还 
可 以 保证 进入 同步 方法 或 者 同步 代码 块 的 每 个 线程 ， 都 看 到 由 同一 个 锁 保 护 的 之 前 所 有 的 修 
改 效果 。 


Java 语 言 规范 保证 读 或 者 写 一 个 变量 是 原子 的 (atomic)， 除 非 这 个 变量 的 类 型 为 long 或 
者 double[JLS，17.4.7]。 换 句 话 说， 读 取 一 个 非 long 或 double 类 型 的 变量 ， 可 以 保证 返回 的 值 
是 某 个 线程 保存 在 该 变量 中 的 ， 即 使 多 个 线程 在 没有 同步 的 情况 下 并 发 地 修改 这 个 变量 也 是 
如 此 。 
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你 可 能 听 说 过 ， 为 了 提高 性 能 ， 在 读 或 写 原子 数据 的 时 候 ， 应 该 避免 使 用 同步 。 这 个 建 
议 是 非常 危险 而 错误 的 。 虽 然 语言 规范 保证 了 线程 在 读 取 原 子 数 据 的 时 候 ， 不 会 看 到 任意 的 
数值 ， 但 是 它 并 不 保证 一 个 线程 写 入 的 值 对 于 另 一 个 线程 将 是 可 见 的 。 为 了 在 线程 之 间 进 行 
可 靠 的 通信 ， 也 为 了 互 斥 访 问 ， 同步 是 必要 的 。 这 归 因 于 Java 语 言 规范 中 的 内 存 模 型 
(memory model) ， 它 规定 了 一 个 线程 所 做 的 变化 何 时 以 及 如 何 变 成 对 其 他 线程 可 见 [JLS, 17， 
Goetz06 16], 


如 果 对 共享 的 可 变数 据 的 访问 不 能 同步 ， 其 后 果 将 非常 可 怕 ， 即 使 这 个 变量 是 原子 可 读 写 
的 。 考 虑 下 面 这 个 阻止 一 个 线程 妨碍 另 一 个 线程 的 任务 。Java 的 类 库 中 提供 了 Thread.stop 方 
法 ， 但 是 这 个 方法 在 很 久 以 前 就 不 提倡 使 用 ， 因 为 它 本 质 上 是 不 安全 的 (unsafe) 一 一 使 用 它 
会 导致 数据 遭 到 破坏 。 不 要 使 用 Thread.stop。 要 阻止 一 个 线程 妨碍 另 一 个 线程 ， 建 议 做 法 是 
让 第 一 个 线程 轮 询 (poll) 一 个 boolean 域 ， 这 个 域 一 开始 为 false， 但 是 可 以 通过 第 二 个 线程 
设置 为 true， 以 表示 第 一 个 线程 将 终止 自己 。 由 于 boolean 域 的 读 和 写 操作 都 是 原子 的 ， 程 序 
员 在 访问 这 个 域 的 时 候 不 再 使 用 同步 ， 

// Broken! - How long would you expect this program to run? 

public class StopThread { 

private static boolean stopRequested; 
public static void main(String[] args) 
throws InterruptedException { 
Thread backgroundThread = new Thread(new Runnable() { 
public void a { 
white i 
i++; 
3); 
backgroundThread.start(); 
TimeUnit.SECONDS.sleep(1); 
$ stopRequested = true; 

} 

你 可 能 期 待 这 个 程序 运行 大 约 一 秒 钟 左 右 ， 之 后 主线 程 将 stopRequested 设 置 为 true， 致 
使 后 台 线程 的 循环 终止 。 但 是 在 我 的 机 器 上 ， 这 个 程序 永远 不 会 终止 : 因为 后 台 线程 永远 在 
循环 ! 


问题 在 于 ， 由 于 没有 同步 ， 就 不 能 保证 后 台 线 程 何 时 “看 到 ”主线 程 对 stopRequested 的 
值 所 做 的 改变 。 没 有 同步 ， 虚 拟 机 将 这 个 代码 : 


while (!done) 
i++; 


转变 成 这 样 : 
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if (!done) 
while (true) 
i++; 


这 是 可 以 接受 的 。 这 种 优化 称 作 提升 (hoisting) ， 正 是 HopSpot Server VM 的 工作 。 结 果 
是 个 活性 失败 (liveness failure); 这 个 程序 无 法 前 进 。 修 正 这 个 问题 的 一 种 方式 是 同步 访问 
stopRequested 域 。 这 个 程序 会 如 预期 般 在 大 约 一 秒 钟 之 内 终止 : 


// Properly synchronized cooperative thread termination 
_ public class StopThread { 
private static boolean stopRequested; 
private static synchronized void requestStop() { 
stopRequested = true; 


private static synchronized boolean stopRequested() { 
return stopRequested; 


public static void main(String[] args) 
throws InterruptedException { 
Thread backgroundThread = new Thread(new Runnable() { 
public void run() { 
int i = 0; 
while (!stopRequested()) 
itt; 


} 
H: 
backgroundThread.start(); 


TimeUnit.SECONDS.sleep(1); 
requestStop(); 
} 
} 


注意 写 方 法 (requestStop) 和 读 方 法 (stopRequested) 都 被 同步 了 。 只 同步 写 方 法 还 不 
够 ! 实际 上 ， 如 果 读 和 写 操作 没有 都 被 同步 ， 同 步 就 不 会 起 作用 。 


StopThread 中 被 同步 方法 的 动作 即使 没有 同步 也 是 原子 的 。 换 句 话 说， 这 些 方法 的 同步 只 
是 为 了 它 的 通信 效果 ， 而 不 是 为 了 互 斥 访问 。 虽 然 循环 的 每 个 迭代 中 的 同步 开销 很 小 ， 还 是 
有 其 他 更 正确 的 替代 方法 ， 它 更 加 简洁 ， 性 能 也 可 能 更 好 。 如 果 stopRequested 被 声明 为 
volatile， 第 二 种 版 本 的 StopThread 中 的 锁 就 可 以 省 略 。 虽 然 volatile 修 饰 符 不 执行 互 斥 访问 ， 
但 它 可 以 保证 任何 一 个 线程 在 读 取 该 域 的 时 候 都 将 看 到 最 近 刚 刚 被 写 入 的 值 :; 


// Cooperative thread termination with a volatile field 
public class StopThread { 
private static volatile boolean stopRequested; 


public static void main(String[] args) 
throws InterruptedException { 
Thread backgroundThread = new Thread(new Runnable() { 
public void runo) { 
int i = 0; 
while (!stopRequested) 
i++; 
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DD; 

backgroundThread. start(); 
TimeUnit.SECONDS.sleep(1); 
stopRequested = true; 


} 
}! 


在 使 用 volatile 的 时 候 务必 要 小 心 。 考 虑 下 面 的 方法 ， 假 设 它 要 产生 序列 号 : 


// Broken - requires synchronization! 
private static volatile int nextSerialNumber = 0; 


public static int generateSerialNumber() { 
return nextSerialNumber++; 


这 个 方法 的 目的 是 要 确保 每 个 调用 都 返回 不 同 的 值 (只 要 不 超过 22 个 调用 ) 。 这 个 方法 的 状 
态 只 包含 一 个 可 原子 访问 的 域 : nextSerialNumber， 这 个 域 的 所 有 可 能 的 值 都 是 合法 的 。 因 此 ， 
不 需要 任何 同步 来 保护 它 的 约束 条 件 。 然 而 ， 如 果 没 有 同步 ， 这 个 方法 仍然 无 法 正常 工作 。 


问题 在 于 ， 增 量 操 作 符 (++) 不 是 原子 的 。 它 在 nextSerialNumber 域 中 执行 两 项 操作 : 首 
先 它 读 取 值 ， 然 后 写 回 一 个 新 值 ， 相 当 于 原来 的 值 再 加 上 1。 如 果 第 二 个 线程 在 第 一 个 线程 读 
取 旧 值 和 写 回 新 值 期 间 读 取 这 个 域 ， 第 二 个 线程 就 会 与 第 一 个 线程 一 起 看 到 同一 个 值 ， 并 返 
回 相 同 的 序列 号 。 这 就 是 安全 性 失败 (safety failure): 这 个 程序 会 计算 出 错误 的 结果 。 


修正 generateSerialNumber 方 法 的 一 种 方法 是 在 它 的 声明 中 增加 synchronized 修 饰 符 。 这 
样 可 以 确保 多 个 调用 不 会 交叉 存 取 ， 确 保 每 个 调用 都 会 看 到 之 前 所 有 调用 的 效果 。 一 旦 这 人 么 
做 ， 就 可 以 且 应 该 从 nextSerialNumber 中 删除 volatile 修 饰 符 。 为 了 让 这 个 方法 更 可 靠 ， 要 用 
long 代 替 int， 或 者 在 nextSerialNumber 快 要 重 释 时 抛 出 异常 。 


最 好 还 是 遵循 第 47 条 中 的 建议 ， 使 用 类 AtomicLong， 它 是 java.util.concurrent.atomic 的 
一 部 分 。 它 所 做 的 工作 正 是 你 想 要 的 ， 并 且 有 可 能 比 同 步 版 的 generateSerialNumber 执 行 得 
更 好 : 


private static final AtomicLong nextSerialNum = new AtomicLong(); 


public static long generateSerialNumber() { 
return nextSerialNum.getAndIncrement() ; 


避免 本 条 目 中 所 讨论 到 的 问题 的 最 佳 办 法 是 不 共享 可 变 的 数据 。 要 么 共享 不 可 变 的 数据 
( 见 第 15 条 ) ， 要 么 压根 不 共享 。 换 名 话说， 将 可 变数 据 限 制 在 单个 线程 中 。 如 果 采 用 这 一 策 
略 ， 对 它 建 立 文档 就 很 重要 ， 以 便 它 可 以 随 着 程序 的 发 展 而 得 到 维护 。 深 刻 地 理解 正在 使 用 
的 框架 和 类 库 也 很 重要 ， 因 为 它们 引入 了 你 所 不 知道 的 线程 。 
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让 一 个 线程 在 短 时 间 内 修改 一 个 数据 对 象 ， 然 后 与 其 他 线程 共享 ， 这 是 可 以 接受 的 ， 只 同 
步 共 享 对 象 引用 的 动作 。 然 后 其 他 线程 没有 进一步 的 同步 也 可 以 读 取 对 象 ， 只 要 它 没 有 再 被 
修改 。 这 种 对 象 被 称 作 事实 上 不 可 变 的 (effectively immutable) [Goetz06 3.5.4]。 将 这 种 对 
象 引 用 从 一 个 线程 传递 到 其 他 的 线程 被 称 作 安全 发 布 (safe publication) [Goetz06 3.5.3]. 
安全 发 布 对 象 引 用 有 许多 种 方法 : 可 以 将 它 保 存在 静态 域 中 ， 作 为 类 初始 化 的 一 部 分 ， 可 以 
将 它 保 存在 volatile 域 、final 域 或 者 通过 正常 锁定 访问 的 域 中 ， 或 者 可 以 将 它 放 到 并 发 的 集合 
中 ( 见 第 69 条 )。 


简 而 言 之 ， 当 多 个 线程 共享 可 变数 据 的 时 候 ， 每 个 读 或 者 写 数据 的 线程 都 必须 执行 同步 。 
如 果 没 有 同步 ， 就 无 法 保证 一 个 线程 所 做 的 修改 可 以 被 另 一 个 线程 获知 。 未 能 同步 共享 可 变 
数据 会 造成 程序 的 活性 失败 (liveness failure) 和 安全 性 失败 (safety failure)。 这 样 的 失败 
是 最 难以 调试 的 。 它 们 可 能 是 间歇 性 的 ， 且 与 时 间 相 关 ， 程序 的 行为 在 不 同 的 YM 上 可 能 根本 
不 同 。 如 果 只 需要 线程 之 间 的 交互 通信 ， 而 不 需要 互 斥 ，volatile 修 饰 符 就 是 一 种 可 以 接受 的 
同步 形式 ， 但 要 正确 地 使 用 它 可 能 需要 一 些 技巧 。 
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第 66 条 告诫 我 们 缺少 同步 的 危险 性 。 本 条 目 则 关注 相反 的 问题 。 依 据 情况 的 不 同 ， 过 度 
同步 可 能 会 导致 性 能 降低 、 死 锁 ， 甚 至 不 确定 的 行为 。 


为 了 避免 活性 失败 和 安全 性 失败 ， 在 一 个 被 同步 的 方法 或 者 代码 块 中 ， 永 远 不 要 放弃 对 客 
户 端 的 控制 。 换 句 话说 ， 在 一 个 被 同步 的 区 域内 部 ， 不 要 调用 设计 成 要 被 覆盖 的 方法 ， 或 者 
是 由 客户 端 以 函数 对 象 的 形式 提供 的 方法 ( 见 第 21 条 )。 从 包含 该 同步 区 域 的 类 的 角度 来 看 ， 
这 样 的 方法 是 外 来 的 (alien)。 这 个 类 不 知道 该 方法 会 做 什么 事情 ， 也 无 法 控制 它 。 根 据 外 来 
方法 的 作用 ， 从 同步 区 域 中 调用 它 会 导致 异常 、 死 锁 或 者 数据 损坏 。 


为 了 对 这 个 过 程 进行 更 具体 的 说 明 ， 来 考虑 下 面 的 类 ， 它 实现 了 一 个 可 以 观察 到 的 集合 包 
装 (set wrapper)。 该 类 允许 客户 端 在 将 元 素 添 加 到 集合 中 时 预订 通知 。 这 就 是 观察 者 
(Observer) 模式 [Gamma95, p.293]。 为 了 简洁 起 见 ， 类 在 从 集合 中 删除 元 素 时 没有 提供 通知 ， 
但 要 提供 通知 也 是 件 很 容易 的 事情 。 这 个 类 是 在 第 73 页 第 16 条 中 可 重用 的 ForwardingSet 上 实 
现 的 : 


// Broken - invokes alien method from synchronized block! 
public class ObservableSet<E> extends ForwardingSet<E> { 
public ObservableSet(Set<E> set) { super(set); } 


private final List<SetObserver<E>> observers = 
new ArrayList<SetObserver<E>>(); 


public void addObserver(SetObserver<E> observer) { 
synchronized(observers) { 
observers .add(observer) ; 


} 
public boolean removeObserver(SetObserver<E> observer) { 
synchronized(observers) { 
return observers.remove(observer) ; 


} 
private void notifyElementAdded(E element) { 
synchronized(observers) { 
for (SetObserver<E> observer : observers) 
observer.added(this, element); 
} 
} 
@Override public boolean add(E element) { 
boolean added = super.add(element); 
if (added) 
noti fyElementAdded(element) ; 
return added; 


@Override public boolean addAl1(Collection<? extends E> c) { 
boolean result = false; 
for (E element : c) 
result |= add(element); // calls notifyElementAdded 
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return result; 


} 


Observer 通过 调用 addObserver 方 法 预订 通知 ， 通 过 调用 removeObserver 方 法 取消 预订 。 
在 这 两 种 情况 下 ， 这 个 回调 接 口 的 实例 都 会 被 传递 给 方法 : 


public interface SetObserver<E> { 
// Invoked when an element is added to the observable set 
void added(ObservableSet<E> set, E element); 

} 


如 果 只 是 粗略 地 检验 一 下 ，ObservableSet 会 显得 很 正常 。 例 如 ， 下 面 的 程序 打印 出 0 ~99 
的 数字 : 
public static void main(String[] args) { 
ObservableSet<Integer> set = 
new ObservableSet<Integer>(new HashSet<Integer>()); 
set.addObserver(new SetObserver<Integer>() { 
public void added(ObservableSet<Integer> s, Integer e) { 
System.out.printin(e); 
DD; 


for (int i = 0; i < 100; i++) 
set.add(i); 
} 


现在 我 们 来 尝试 一 些 更 复杂 点 的 例子 。 假设 我 们 用 一 个 addObserver 调 用 来 代替 这 个 调用 ， 
用 来 替换 的 那个 addObserver 调 用 传递 了 一 个 打印 Integer 值 的 观察 者 ， 这 个 值 被 添加 到 该 集合 
中 ， 如 果 值 为 23， 这 个 观察 者 要 将 自身 删除 : 


set.addObserver(new SetObserver<Integer>() { 
public void added(ObservableSet<Integer> s, Integer e) { 
System.out.printin(e); 
if (e == 23) s.removeObserver(this); 


} 
H; 


你 可 能 以 为 这 个 程序 会 打印 0 ~23 的 数字 ， 之 后 观察 者 会 取消 预订 ， 程序 会 悄悄 地 完成 它 
的 工作 。 实 际 上 却 是 打印 出 0 ~23 的 数字 ， 然 后 抛 出 ConcurrentModificationException。 问 题 
在 于 ， 当 notifyElementAdded 调 用 观察 者 的 added 方 法 时 ， 它 正 处 于 遍历 observers 列 表 的 过 程 
中 。added 方 法 调用 可 观察 集合 的 removeObserver 方 法 ， 从 而 调用 observers.remove。 现 在 我 
们 有 麻烦 了 。 我 们 正 企 图 在 遍历 列表 的 过 程 中 ， 将 一 个 元 素 从 列表 中 删除 ， 这 是 非法 的 。 
notifyElementAdded 方 法 中 的 迭代 是 在 一 个 同步 的 块 中 ， 可 以 防止 并 发 的 修改 ,但 是 无 法 防止 
迭代 线程 本 身 回调 到 可 观察 的 集合 中 ， 也 无 法 防止 修改 它 的 Observers 列 表 。 


现在 我 们 要 尝试 一 些 比较 奇特 的 例子 : 我 们 来 编写 一 个 试图 取消 预订 的 观察 者 ， 但 是 不 直 
接 调用 removeObserver， 它 用 另 一 个 线程 的 服务 来 完成 。 这 个 观察 者 使 用 了 一 个 executor 
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service ( 14684): 
// Observer that uses a background thread needlessly 
set.addObserver(new SetObserver<Integer>() { 
public void added(final ObservableSet<Integer> s, Integer e) { 
System.out.printin(e) ; 
if (e == 23) { 
ExecutorService executor = 
Executors.newSingleThreadExecutor(); 
final SetObserver<Integer> observer = this; 
try { 
executor. submit(new Runnable() { 
` public void run() 
s.removeObserver (observer); 
} 
}).getO; 
} catch (ExecutionException ex) { 
throw new AssertionError(ex.getCause()); 
} catch (InterruptedException ex) { 
throw new AssertionError(ex.getCause()); 
} finally { 
executor. shutdown() ; 
} 
} 
Hi; 
这 一 次 我 们 没有 遇 到 异常 ， 而 是 遭遇 了 死 锁 。 后 人 台 线 程 调用 s.removeObserver， 它 企图 锁 
定 observers， 但 它 无 法 获得 该 锁 ， 因 为 主线 程 已 经 有 锁 了 。 在 这 期 间 ， 主 线程 一 直 在 等 待 后 


台 线 程 来 完成 对 观察 者 的 删除 ， 这 正 是 造成 死 锁 的 原因 。 


这 个 例子 是 刻意 编写 用 来 示范 的 ， 因 为 观察 者 实际 上 没 理由 使 用 后 台 线程 ， 但 这 个 问题 
却 是 真实 的 。 从 同步 区 域 中 调用 外 来 方法 ， 在 真实 的 系统 中 已 经 造成 了 许多 死 锁 ， 例 如 GUI 
工具 箱 。 


在 前 面 这 两 个 例子 中 (异常 和 死 锁 ) ， 我 们 都 还 算 幸 运 的 。 调 用 外 来 方法 (added) 时 ， 
同步 区 域 (observers) 所 保护 的 资源 处 于 一 致 的 状态 。 假设 当 同 步 区 域 所 保护 的 约束 条 件 暂 
时 无 效 时 ， 你 要 从 同步 区 域 中 调用 一 个 外 来 方法 。 由 于 Java 程 序 设计 语言 中 的 锁 是 可 重 入 的 
(reentrant) ， 这 种 调用 不 会 死 锁 。 就 像 在 第 一 个 例子 中 一 样 ， 它 会 产生 一 个 异常 ， 因 为 调用 线 
程 已 经 有 这 个 锁 了 ， 因 此 当 该 线程 试图 再 次 获得 该 锁 时 会 成 功 ， 尽 管 概念 上 不 相关 的 另 一 项 
操作 正在 该 锁 所 保护 的 数据 上 进行 着 。 这 种 失败 的 后 果 可 能 是 灾难 性 的 。 从 本 质 上 来 说 ， 这 
个 锁 没 有 尽 到 它 的 职责 。 可 再 人 的 锁 简 化 了 多 线程 的 面向 对 象 程 序 的 构造 ， 但 是 它们 可 能 会 
将 活性 失败 (lireness failure) 变 成 安全 性 失败 (safety failure ) 。 


幸运 的 是 ， 通 过 将 外 来 方法 的 调用 移出 同步 的 代码 块 来 解决 这 个 问题 通常 并 不 太 困 难 。 对 
于 notifyElementAdded 方 法 ， 这 还 涉及 给 observers 列 表 拍 张 “快照 "， 然 后 没有 锁 也 可 以 安全 
地 遍历 这 个 列表 了 。 经 过 这 一 修改 ， 前 两 个 例子 运行 起 来 便 再 也 不 会 出 现 异常 或 者 死 锁 了 : 


// Alien method moved outside of synchronized block - open calls 
private void notifyElementAdded(E element) { 
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List<SetObserver<E>> snapshot = null; 
synchronized(observers) { 
snapshot = new ArrayList<SetObserver<E>>(observers) ; 


for (SetObserver<E> observer : snapshot) 
observer.added(this, element); 
} 


事实 上 ， 要 将 外 来 方法 的 调用 移出 同步 的 代码 块 ， 还 有 一 种 更 好 的 方法 。 自 从 Java 1.5% 
行 版 本 以 来 ，Java 类 库 就 提供 了 一 个 并 发 集合 (concurrent collection ) ， 见 第 69 条 ， 称 作 
CopyOnWriteArrayList， 这 是 专门 为 此 定制 的 。 这 是 ArrayList 的 一 种 变 体 ， 通 过 重新 拷贝 整 
个 底层 数组 ， 在 这 里 实现 所 有 的 写 操作 。 由 于 内 部 数组 永远 不 改动 ， 因 此 和 迭代 不 需要 锁定 ， 
速度 也 非常 快 。 如 果 大 量 使 用 ，CopyOnWriteArrayEist 的 性 能 将 大 受 影 响 ， 但 是 对 于 观察 者 
列表 来 说 却 是 很 好 的 ， 因 为 它们 几乎 不 改动 ， 并 且 经 常 被 遍历 。 


如 果 这 个 列表 改 成 使 用 CopyOnWriteArrayList， 就 不 必 改 动 ObservableSet 的 add 和 addAll 


方法 。 下 面 是 这 个 类 的 其 余 代 码 。 注 意 其 中 并 没有 任何 显 式 的 同步 。 
// Thread-safe observable set with CopyOnWriteArrayList 
private final List<SetObserver<E>> observers = ; 
new CopyOnWriteArrayList<SetObserver<E>>(); 


public void addObserver(SetObserver<E> observer) { 
observers.add(observer) ; 


public boolean removeObserver(SetObserver<E> observer) { 
return observers. remove(observer); 


private void notifyElementAdded(E element) { 


for (SetObserver<E> observer : observers) 
observer.added(this, element); 
} : 


在 同步 区 域 之 外 被 调用 的 外 来 方法 被 称 作 “开放 调用 (open call)” [Lea00, 2.4.1.3], BR 
了 可 以 避免 死 锁 之 外 ， 开 放 调 用 还 可 以 极 大 地 增加 并 发 性 。 外 来 方法 的 运行 时 间 可 能 会 任意 
长 。 如 果 在 同步 区 域内 调用 外 来 方法 ， 其 他 线程 对 受 保护 资源 的 访问 就 会 遭 到 不 必要 的 拒绝 。 


通常 ， 你 应 该 在 同步 区 域内 做 尽 可 能 少 的 工作 。 获 得 锁 ， 检 查 共 享 数据 ， 根 据 需要 转换 数 
据 ， 然 后 放 掉 锁 。 如 果 你 必须 要 执行 某 个 很 耗 时 的 动作 ， 则 应 该 设法 把 这 个 动作 移 到 同步 区 
域 的 外 面 ， 而 不 违背 第 66 条 中 的 指导 方针 。 


本 条 目的 第 一 部 分 是 关于 正确 性 的 。 接 下 来 ,我 们 要 简单 地 讨论 一 下 性 能 。 虽 然 自 从 Java 
平台 早期 以 来 ， 同 步 的 成 本 已 经 下 降 了 ， 但 更 重要 的 是 ， 永 远 不 要 过 关 同 步 。 在 这 个 多 核 的 
时 代 ， 过 度 同步 的 实际 成 本 并 不 是 指 获取 锁 所 花费 的 CPU 时 间 ， 而 是 指 失去 了 并 行 的 机 会 ， 
以 及 因为 需要 确保 每 个 核 都 有 一 个 一 致 的 内 存 视图 而 导致 的 延迟 。 过 度 同步 的 另 一 项 法 在 开 
销 在 于 ， 它 会 限制 YM 优化 代码 执行 的 能 力 。 


如 果 一 个 可 变 的 类 要 并 发 使 用 ， 应 该 使 这 个 类 变 成 是 线程 安全 的 ( 见 第 70 条 )， 通 过 内 部 
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同步 ， 你 还 可 以 获得 明显 比 从 外 部 锁定 整个 对 象 更 高 的 并 发 性 。 否 则 ， 就 不 要 在 内 部 同步 。 
让 客户 在 必要 的 时 候 从 外 部 同步 。 在 Java 平 台 出 现 的 早期 ， 许 多 类 都 违背 了 这 些 指导 方针 。 例 
如 ，StringBuffer 实 例 几 乎 总 是 被 用 于 单个 线程 之 中 ， 而 它们 执行 的 却 是 内 部 同步 。 为 此 ， 
StringBuffer 基 本 上 都 由 StringBuilder 代 赫 , 它 在 Java 1.5 发 行 版 本 中 是 个 非 同 步 的 StringBuffer。 
当 你 不 确定 的 时 候 ， 就 不 要 同步 你 的 类 ， 而 是 应 该 建立 文档 ， 注 明 它 不 是 线程 安全 的 ( 见 第 
70 条 )。 


如 果 你 在 内 部 同步 了 类 ， 就 可 以 使 用 不 同 的 方法 来 实现 高 并 发 性 ， 例 如 分 拆 锁 (lock 
splitting) 、 分 离 锁 (lock striping) 和 非 阻塞 (nonblocking) 并 发 控制 。 这 些 方法 都 超出 了 本 
书 的 讨论 范围 ， 但 有 其 他 著作 对 此 进行 了 阐述 [Goetz06, Lea00]。 : 


如 果 方 法 修改 了 静态 域 ， 那么 你 也 必须 同步 对 这 个 域 的 访问 , 即使 它 往 往 只 用 于 单个 线程 。 
客户 要 在 这 种 方法 上 执行 外 部 同步 是 不 可 能 的 ， 因 为 不 可 能 保证 其 他 不 相关 的 客户 也 会 执行 
外 部 同步 。 第 232 页 中 的 generateSerialNumber 方 法 就 是 这 样 的 一 个 例子 。 


简 而 言 之 ， 为 了 避免 死 锁 和 数据 破坏 ， 千 万 不 要 从 同步 区 域内 部 调用 外 来 方法 。 更 为 一 般 
地 讲 ， 要 尽量 限制 同步 区 域内 部 的 工作 量 。 当 你 在 设计 一 个 可 变 类 的 时 候 ， 要 考虑 一 下 它们 
是 否 应 该 自己 完成 同步 操作 。 在 现在 这 个 多 核 的 时 代 ， 这 上 比 永远 不 要 过 度 同 步 来 得 更 重要 。 
只 有 当 你 有 足够 的 理由 一 定 要 在 内 部 同步 类 的 时 候 ， 才 应 该 这 么 做 ， 同 时 还 应 该 将 这 个 决定 
清楚 地 写 到 文档 中 〈 见 第 70 条 ) 。 





本 书 第 1 版 中 阅 述 了 简单 的 工作 队列 (work queue) [Bloch01， 见 第 50 条 ] 的 代码 。 这 个 类 人 允 
许 客户 将 后 台 线 程 异步 处 理 的 工作 项 目 加 入 队列 (enqueue)。 当 不 再 需要 这 个 工作 队列 时 ， 客 户 
端 可 以 调用 一 个 方法 ， 让 后 台 线 程 在 完成 了 已 经 在 队列 中 的 所 有 工作 之 后 ， 优 雅 地 终止 自己 。 这 
个 实现 几乎 就 像 件 玩具 ， 但 即使 如 此 ， 它 还 是 需要 一 整 页 精细 的 代码 ， 一 不 小 心 ， 就 容易 出 现 安 
全 问题 或 者 导致 活性 失败 (liveness failure) 。 幸 运 的 是 ， 你 再 也 不 需要 编写 这 样 的 代码 了 。 


在 Java 1.5 发 行 版 本 中 ，Java 平 台中 增加 了 java.util.concurrent。 这 个 包 中 包含 了 一 个 
Executor Framework， 这 是 一 个 很 灵活 的 基于 接口 的 任务 执行 工具 。 它 创建 了 一 个 在 各 方面 
都 比 本 书 第 一 版 更 好 的 工作 队列 ， 却 只 需要 这 一 行 代码 : 


ExecutorService executor = Executors.newSingleThreadExecutor(); 


下 面 是 为 执行 提交 一 个 runnable 的 方法 : 


executor.execute(runnable) ; 


下 面 是 告诉 executor 如 何 优雅 地 终止 (如 果 做 不 到 这 一 点 ， 虚 拟 机 可 能 将 不 会 退出 ): 


executor. shutdown() ; 


你 可 以 利用 executor service 完 成 更 多 的 事情 。 例 如 ， 可 以 等 待 完 成 一 项 特殊 的 任务 (就 如 
第 236 页 第 67 条 中 的 “后 台 线 程 SetObserver” 中 的 一 样 )， 你 可 以 等 待 一 个 任务 集合 中 的 任何 
任务 或 者 所 有 任务 完成 (利用 invokeAny 或 者 invokeAll 方 法 )， 你 可 以 等 待 executor service 优 
雅 地 完成 终止 (利用 awaitTermination 方 法 )， 你 可 以 在 任务 完成 时 逐个 地 获取 这 些 任 务 的 结 
果 (利用 ExecutorCompletionService)， 等 等 。 


”如果 想 让 不 止 一 个 线程 来 处 理 来 自 这 个 队列 的 请 求 ， 只 要 调用 一 个 不 同 的 静态 工厂 ， 这 个 
工厂 创建 了 一 种 不 同 的 executor service， 称 作 线 程 池 (thread pool)。 你 可 以 用 固定 或 者 可 变 
数目 的 线程 创建 一 个 线程 池 。java.util.concurrent.Executors 类 包含 了 静态 工厂 ， 能 为 你 提供 所 
需 的 大 多 数 executor。 然 而 ， 如 果 你 想来 点 特别 的 ， 可 以 直接 使 用 ThreadPoolExecutor 类 。 这 
个 类 允许 你 控制 线程 池 操 作 的 几乎 每 个 方面 。 


` 为 特殊 的 应 用 程序 选择 executor service 是 很 有 技巧 的 。 如 果 编 写 的 是 小 程序 ， 或 者 是 轻 载 
的 服务 器 ， 使 用 Executors.newCachedThreadPool 通 常 是 个 不 错 的 选择 ， 因 为 它 不 需要 配置 ， 
并 且 一 般 情 况 下 能 够 正确 地 完成 工作 。 但 是 对 于 大 负载 的 服务 器 来 说 ， 缓 存 的 线程 池 就 不 是 
很 好 的 选择 了 ! 在 缓存 的 线程 池 中 ， 被 提交 的 任务 没有 排 成 队列 ， 而 是 直接 交 给 线程 执行 。 
如 果 没 有 线程 可 用 ， 就 创建 一 个 新 的 线程 。 如 果 服 务 器 负载 得 太 重 ， 以 致 它 所 有 的 CPU 都 完 
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全 被 占用 了 ， 当 有 更 多 的 任务 时 ， 就 会 创建 更 多 的 线程 ， 这 样 只 会 使 情况 变 得 更 糟 。 因 此 ， 
在 大 负载 的 产品 服务 器 中 ， 最 好 使 用 Executors.newFixedThreadPool， 它 为 你 提供 了 一 个 包含 
固定 线程 数目 的 线程 地 ， 或 者 为 了 最 大 限度 地 控制 它 ， 就 直接 使 用 ThreadPoolExecutor 类 。 


你 不 仅 应 该 尽量 不 要 编写 自己 的 工作 队列 ， 而 且 还 应 该 尽量 不 直接 使 用 线程 。 现 在 关键 的 
抽象 不 再 是 Thread 了 ， 它 以 前 可 是 既 充 当 工 作 单元 ， 又 是 执行 机 制 。 现 在 工作 单元 和 执行 机 
制 是 分 开 的 。 现 在 关键 的 抽象 是 工作 单元 ， 称 作 任务 (task)。 任 务 有 两 种 : Runnable 及 其 近 
亲 Callable ( 它 与 Runnable 类 似 ， 但 它 会 返回 值 ) 。 执 行 任务 的 通用 机 制 是 executor service, 
如 果 你 从 任务 的 角度 来 看 问题 ， 并 让 一 个 executor service 替 你 执行 任务 ， 在 选择 适当 的 执行 
策略 方面 就 获得 了 极 大 的 灵活 性 。 从 本 质 上 讲 ，Executor Famework 所 做 的 工作 是 执行 ， 犹 如 
Collections Framework 所 做 的 工作 是 聚集 (aggregation) 一 样 。 


Executor Framework 也 有 一 个 可 以 代替 java.util.Timer 的 东西 ， 即 ScheduledThreadPool- 
Executor。 虽 然 timer 使 用 起 来 更 加 容易 ， 但 是 被 调度 的 线程 地 executor 更 加 灵活 。timer 只 用 
一 个 线程 来 执行 任务 ， 这 在 面 对 长 期 运行 的 任务 时 ， 会 影响 到 定时 的 准确 性 。 如 果 timer 唯 一 
的 线程 抛 出 未 被 捕获 的 异常 ，timer 就 会 停止 执行 。 被 调度 的 线程 池 executor 支 持 多 个 线程 ， 
并 且 优 雅 地 从 抛 出 未 受 检 蜡 常 的 任务 中 恢复 。 


Executor Framework 的 完整 处 理 方法 超出 了 本 书 的 讨论 范围 ， 但 是 有 兴趣 的 读者 可 以 参阅 


«Java Concurrency in Practice} 9— 书 [Goetz06]。 


日 ”中 文 版 为 《Java 并 发 编程 实践 》 书 号 为 978-7-121-04316-1。 一 一 译 者 注 
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本 书 第 1 版 中 专门 用 了 一 个 条 目 来 说 明 如 何 正确 地 使 用 wait 和 notify (BlochO1, 见 第 50 条 ) 。 
它 提出 的 建议 仍然 有 效 ， 并 且 在 本 条 目的 最 后 也 对 此 做 了 概述 ， 但 是 这 条 建议 现在 远 远 没有 
之 前 那么 重要 了 。 这 是 因为 几乎 没有 理由 再 使 用 wait 和 notify 了 。 自 从 Java 1.5 发 行 版 本 开始 ， 
Java 平 台 就 提供 了 更 高 级 的 并 发 工具 ， 它 们 可 以 完成 以 前 必须 在 wait 和 notify 上 手写 代码 来 完 
成 的 各 项 工作 。 了 既然 正确 地 使 用 wait 和 mnotify 比 较 困 难 ， 就 应 该 用 更 高 级 的 并 发 工具 来 代替 。 


java.util.concurrent 中 更 高 级 的 工具 分 成 三 类 : Executor Framework, HR RKA 
(Concurrent Collectioin) 以 及 同步 器 (Synchronizer), Executor Framework 只 在 第 68 条 中 简 
单 地 提 到 过 。 并 发 集合 和 同步 器 将 在 本 条 目 中 进行 简单 的 阐述 。 


并 发 集合 为 标准 的 集合 接口 (如 List、Queue 和 Map) 提供 了 高 性 能 的 并 发 实现 。 为 了 提 
供 高 并 发 性 ， 这 些 实现 在 内 部 自己 管理 同步 〈 见 第 67 条 )。 因 此 ， 并 发 集合 中 不 可 能 排除 并 发 
活动 ;将 它 锁定 没有 什么 作用 ， 只 会 使 程序 的 速度 变 慢 。 


这 意味 着 客户 无 法 原子 地 对 并 发 集合 进行 方法 调用 。 因 此 有 些 集合 接口 已 经 通过 依赖 状态 
的 修改 操作 (state-dependent modify operation) 进行 了 扩展 ， 它 将 几 个 基本 操作 合并 到 了 单 
个 原子 操作 中 。 例 如 ，ConcurrentMap 扩 展 了 Map 接 口 ， 并 添加 了 几 个 方法 ， 包 括 
putlfAbsent(key, value)， 当 键 没有 映射 时 会 奉 它 插入 一 个 映射 ， 并 返回 与 键 关联 的 前 一 个 值 ， 
如 果 没 有 这 样 的 值 ， 则 返回 null。 这 样 使 得 实现 线程 安全 的 标准 Map 就 很 容易 了 。 例 如 ， 下 面 
这 个 方法 模拟 了 String.intern 的 行为 : 


// Concurrent canonicalizing map atop ConcurrentMap - not optimal 
private static final ConcurrentMap<String, String> map = 
new ConcurrentHashMap<String, String>(); 


public static String intern(String s) { 
String previousValue = map.putIfAbsent(s, s); 
return previousValue == null ? s : previousValue; 


} 


事实 上 ， 你 还 可 以 做 得 更 好 。ConcurrentHashMap 对 获取 操作 (如 get) 进行 了 优化 。 
此 ， 只 有 当 get 表 明 有 必要 的 时 候 ， 才 值得 先 调 用 get， 再 调用 putIfAbsent: 


// Concurrent canonicalizing map atop ConcurrentMap - faster! 
public static String intern(String s) { 
String result = map.get(s); 
if (result == null) { 
result = map.putIfAbsent(s, s); 
if (result == null) 
result = s; 


return result; 
} 
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ConcurrentHashMap 除 了 提供 卓越 的 并 发 性 之 外 ， 速 度 也 非常 快 。 在 我 的 机 器 上 ， 上 面 这 
个 优化 过 的 intern 方 法 比 String.intern 速 度 快 了 超过 6 倍 (但 是 记 住 ，String.intern 必 须 使 用 某 种 
弱 引 用 ， 来 避免 随 着 时 间 的 推移 而 发 生 内 存 泄露 ) 。 除 非 不 得 已 ， 否 则 应 该 优先 使 用 
ConcurrentHashMap， 而 不 是 使 用 Collections.synchronizedMap 或 者 Hashtable。 只 要 用 并 
发 Map 替 换 老 式 的 同步 Map ， 就 可 以 极 大 地 提升 并 发 应 用 程序 的 性 能 。 更 一 般 地 ， 应 该 优先 使 
用 并 发 集合 ， 而 不 是 使 用 外 部 同步 的 集合 。 


有 些 集合 接口 已 经 通过 阻塞 操作 (blocking operation) 进行 了 扩展 ， 它 们 会 一 直 等 待 
(或 者 阻塞 ) 到 可 以 成 功 执行 为 止 。 例 如 ，BlockingQueue 扩 展 了 Queue 接 口 ， 并 添加 了 包括 
take 在 内 的 几 个 方法 ， 它 从 队列 中 删除 并 返回 了 头 元 素 ， 如 果 队 列 为 空 ， 就 等 待 。 这 样 就 允许 
将 阻塞 队列 用 于 工作 队列 (work queue)， 也 称 作 生产 者 一 消费 者 队列 (producer-consumer 
queue) ， 一 个 或 者 多 个 生产 者 线程 (producer thread) 在 工作 队列 中 添加 工作 项 目 ， 并 且 当 
工作 项 目 可 用 时 ， 一 个 或 者 多 个 消费 者 线程 (consumer thread) 则 从 工作 队列 中 取出 队列 并 
处 理工 作 项 目 。 不 出 所 料 ， 大 多 数 ExecutorService 实 现 (包括 ThreadPoolExecutor) 都 使 用 
BlockingQueue ( 见 第 68 条 ) 。 


同步 器 (Synchronizer) 是 一 些 使 线程 能 够 等 待 另 一 个 线程 的 对 象 ， 人 允许 它们 协调 动作 。 
最 常用 的 同步 器 是 CountDownLatch 和 Semaphore。 较 不 常用 的 是 CyclicBarrier 和 Exchanger。 


倒 计 数 锁 存 器 (Countdown Latch) 是 一 次 性 的 障碍 ， 人 允许 一 个 或 者 多 个 线程 等 待 一 个 
或 者 多 个 其 他 线程 来 做 某 些 事情 。CountDownLatch 的 唯一 构造 器 带 有 一 个 int 类 型 的 参数 ， 
这 个 int 参 数 是 指 允 许 所 有 在 等 待 的 线程 被 处 理 之 前 ， 必 须 在 锁 存 器 上 调用 countDown 方 法 
的 次 数 。 


要 在 这 个 简单 的 基本 类 型 之 上 构建 一 些 有 用 的 东西 ， 做 起 来 是 相当 的 容易 。 例 如 ， 假 设想 
要 构建 一 个 简单 的 框架 ， 用 来 给 一 个 动作 的 并 发 执行 定时 。 这 个 框架 中 包含 单个 方法 ， 这 个 
方法 带 有 一 个 执行 该 动作 的 executor， 一 个 并 发 级 别 (表示 要 并 发 执行 该 动作 的 次 数 )， 以 及 
表示 该 动作 的 runnable。 所 有 的 工作 线程 (worker thread) 自身 都 准备 好 ， 要 在 timer 线 程 启动 
时 钟 之 前 运行 该 动作 (为 了 实现 准确 的 定时 ， 这 是 必需 的 ) 。 当 最 后 一 个 工作 线程 准备 好 运行 
该 动作 时 ，timer 线 程 就 “发 起 头 炮 ” ， 同 时 允许 工作 线程 执行 该 动作 。 一 旦 最 后 一 个 工作 线程 
执行 完 该 动作 ，timer 线 程 就 立即 停止 计时 。 直 接 在 wait 和 notify 之 上 实现 这 个 逻辑 至 少 来 说 会 
很 混乱 ， 而 在 CountDownLatch 之 上 实现 则 相当 简单 : 


// Simple framework for timing concurrent execution 
public static long time(Executor executor, int concurrency, 
final Runnable action) throws InterruptedException { 
final CountDownLatch ready = new CountDownLatch(concurrency) ; 
final CountDownLatch start = new CountDownLatch(1); 
final CountDownLatch done = new CountDownLatch(concurrency); 
for (int i = 0; i < concurrency; i++) { 
executor.execute(new Runnable() { - 
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public void rund) { à 
ready.countDown(); // Tell timer we're ready 
try { 

start.await(); // Wait till peers are ready 
action.run(); 
} catch (InterruptedException e) { 
Thread.currentThread().interrupt(); 
} finally { 
done.countDown(); // Tell timer we're done 
} 


} 
E 
J 
ready.await(); // Wait for all workers to be ready 
long startNanos = System.nanoTime(); 
start.countDown(); // And they're off! 
done. await(); // Wait for all workers to finish 
return System.nanoTime() - startNanos; 
} 


注意 这 个 方法 使 用 了 三 个 倒 计 数 锁 存 器 。 第 一 个 是 ready， 工 作 线 程 用 它 来 告诉 timer 线 程 
它们 已 经 淮 备 好 了 。 然 后 工作 线程 在 第 二 个 锁 存 器 上 等 待 ， 也 就 是 start。 当 最 后 一 个 工作 线程 
调用 ready.countDown 上 时 ，timer 线 程 记录 下 起 始 时 间 ， 并 调用 start.countDown， 人 允许 所 有 的 工 
作 线 程 继续 进行 。 然 后 timer 线 程 在 第 三 个 锁 存 器 ( 即 done) 上 等 待 ， 直到 最 后 一 个 工作 线程 
运行 完 该 动作 ， 并 调用 done.countDown。 一 旦 调用 这 个 ，timer 线 程 就 会 苏醒 过 来 ， 并 记录 下 
结束 的 时 间 。 


还 有 一 些 细节 值得 注意 。 传 递 给 time 方 法 的 executor 必 须 允 许 创建 至 少 与 指定 并 发 级 别 一 
样 多 的 线程 ， 否 则 这 个 测试 就 永远 不 会 结束 。 这 就 是 线程 饥 馈 死 锁 (thread starvation 
deadlock) [Goetz06 8.1.1]。 如 果 工 作 线 程 捕捉 到 InterruptedException ， 就 会 利用 习惯 用 法 
Thread.currentThread().interrupt() 重 新 断言 中 断 ， 并 从 它 的 run 方 法 中 返回 。 这 样 就 允许 
executor 在 必要 的 时 候 处 理 中 断 ， 事 实 上 也 理 当 如 此 。 最 后 ， 注 意 利 用 了 System.nanoTime 来 ` 
给 活动 定时 ， 而 不 是 利用 System.currentTimeMillis。 对 于 间 软 式 的 定时 ， 始 终 应 该 优先 使 用 
System.nanoTime， 而 不 是 使 用 System.currentTimeMills 。 System.nanoTime 更 加 准确 也 更 
加 精确 ， 它 不 受 系统 的 实时 时 钟 的 调整 所 影响 。 


本 条 目 仅仅 触及 了 并 发 工具 的 一 些 皮毛 。 例 如 ， 前 一 个 例子 中 的 那 三 个 倒 计 数 锁 存 器 
(CountdownLatch) 其 实 可 以 用 一 个 CyclicBarrier 来 代替 。 这 样 产 生 的 代码 更 加 简洁 ， 但 是 理 
解 起 来 比较 困难 。 更 多 信息 ， 请 参阅 《Java Concurrency in Practice) 一 书 [Goetz06]。 


虽然 你 始终 应 该 优先 使 用 并 发 工具 ， 而 不 是 使 用 wait 和 notify， 但 可 能 必须 维护 使 用 了 
wait 和 notify 的 遗留 代码 。wait 方 法 被 用 来 使 线程 等 待 某 个 条 件 。 它 必须 在 同步 区 域内 部 被 调 
用 ， 这 个 同步 区 域 将 对 象 锁定 在 了 调用 wait 方 法 的 对 象 上 。 下 面 是 使 用 wait 方 法 的 标准 模式 ， 

// The standard idiom for using the wait thy 


synchronized (obj) { 
while (<condition does not hold>) 
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obj.wait(); // (Releases lock, and reacquires on wakeup) 


... // Perform action appropriate to condition 


} 


始终 应 该 使 用 wait 循 环 模式 来 调用 wait 方 法 ; 永远 不 要 在 循环 之 外 调用 wait 方 法 。 循 环 会 
在 等 待 之 前 和 之 后 测试 条 件 。 


在 等 待 之 前 测试 条 件 ， 当 条 件 已 经 成 立时 就 跳 过 等 待 ， 这 对 于 确保 活性 (liveness) 是 必 
要 的 。 如 果 条 件 已 经 成 立 ， 并 且 在 线程 等 待 之 前 ，notify (或 者 notifyAll) 方法 已 经 被 调用 ， 
则 无 法 保证 该 线程 将 会 从 等 待 中 苏醒 过 来 。 


在 等 待 之 后 测试 条 件 , 如 果 条 件 不 成 立 的 话 继 续 等 待 ， 这 对 于 确保 安全 性 (safety) 是 必 
要 的 。 当 条 件 不 成 立 的 时 候 ， 如 果 线 程 继续 执行 ， 则 可 能 会 破坏 被 锁 保护 的 约束 关系 。 当 条 
件 不 成 立时 ， 有 下 面 一 些 理由 可 使 一 个 线程 苏醒 过 来 : 


* 男 一 个 线程 可 能 已 经 得 到 了 锁 ， 并 且 从 一 个 线程 调用 notify 那 一 刻 起 ， 到 等 待 线程 苏 醒 
过 来 的 这 段 时 间 中 ， 得 到 锁 的 线程 已 经 改变 了 受 保护 的 状态 。 


。 条 件 并 不 成 立 ， 但 是 另 一 个 线程 可 能 意外 地 或 恶意 地 调用 了 notify。 在 公有 可 访问 的 对 
象 上 等 待 ， 这 些 类 实际 上 把 自己 暴露 在 了 这 种 危险 的 境地 中 。 公 有 可 访问 对 象 的 同步 方 
法 中 包含 的 wait 都 会 出 现 这 样 的 问题 。 


* 通 知 线程 (notifying thread) 在 唤醒 等 待 线程 时 可 能 会 过 度 “ 大 方 ”"。 例 如 ， 即 使 只 有 
某 一 些 等 待 线程 的 条 件 已 经 被 满足 ， 但 是 通知 线程 可 能 仍然 调用 notifyAll。 


。 在 没有 通知 的 情况 下 ， 等 待 线程 也 可 能 (但 很 少 ) 会 苏醒 过 来 。 这 被 称 为 “ 伪 唤 醒 
(spurious wakeup)” [Posix, 11.4.3.6.1，JavaSE6]。 


一 个 相关 的 话题 是 ， 为 了 唤醒 正在 等 待 的 线程 ， 你 应 该 使 用 notify 还 是 notifyAll (回忆 一 
下 ，notify 唤 醒 的 是 单个 正在 等 待 的 线程 ， 假 设 有 这 样 的 线程 存在 ， 而 notifyAll 唤 醒 的 则 是 所 
有 正在 等 待 的 线程 )。 一 种 常见 的 说 法 是 ， 你 总 是 应 该 使 用 notifyAll。 这 是 合理 而 保守 的 建议 。 
它 总 会 产生 正确 的 结果 ， 因 为 它 可 以 保证 你 将 会 唤醒 所 有 需要 被 唤醒 的 线程 。 你 可 能 也 会 唤 
醒 其 他 一 些 线程 ， 但 是 这 不 会 影响 程序 的 正确 性 。 这 些 线程 醒 来 之 后 ， 会 检查 它们 正在 等 待 
的 条 件 ， 如 果 发 现 条 件 并 不 满足 ， 就 会 继续 等 待 。 


从 优化 的 角度 来 看 ， 如 果 处 于 等 待 状态 的 所 有 线程 都 在 等 待 同一 个 条 件 ， 而 每 次 只 有 一 个 
线程 可 以 从 这 个 条 件 中 被 唤醒 ， 那 么 你 就 应 该 选择 调用 notify ， 而 不 是 notifyAll。 


即使 这 些 条 件 都 是 真 的 ， 也 许 还 是 有 理由 使 用 notifyAll 而 不 是 notify。 就 好 像 把 wait 调 用 
放 在 一 个 循环 中 ， 以 避免 在 公有 可 访问 对 象 上 的 意外 或 恶意 的 通知 一 样 ， 与 此 类 似 ， 使 用 
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notifyAll 代 赫 notify 可 以 避免 来 自 不 相关 线程 的 意外 或 恶意 的 等 待 。 否 则 ， 这 样 的 等 待 会 “ 否 
掉 ” 一 个 关键 的 通知 ， 使 真正 的 接收 线程 无 限 地 等 待 下 去 。 


简 而 言 之 ， 直 接 使 用 wait 和 notify 就 像 用 “并 发 汇编 语言 ”进行 编程 一 样 ， 而 
java.util.concurrent 则 提供 了 更 高 级 的 语言 。 没有 理由 在 新 代码 中 使 用 wait 和 notify， 即 使 有 ， 
也是 极 少 的 。 如 果 你 在 维护 使 用 wait 和 notify 的 代码 ， 务 必 确 保 始终 是 利用 标准 的 模式 从 while 
循环 内 部 调用 wait。 一 般 情况 下 ， 你 应 该 优先 使 用 notifyAll， 而 不 是 使 用 notify。 如 果 使 用 
notify， 请 一 定 要 小 心 ， 以 确保 程序 的 活性 (liveness)。 





当 一 个 类 的 实例 或 者 静态 方法 被 并 发 使 用 的 时 候 ， 这 个 类 的 行为 如 何 ， 是 该 类 与 其 客户 端 
程序 建立 的 约定 的 重要 组 成 部 分 。 如 果 你 没有 在 一 个 类 的 文档 中 描述 其 行为 的 并 发 性 情况 ， 
使 用 这 个 类 的 程序 员 将 不 得 不 做 出 某 些 假 设 。 如 果 这 些 假设 是 错误 的 ， 这 样 得 到 的 程序 就 可 
能 缺少 足够 的 同步 ( 见 第 66 条 )， 或 者 过 度 同 步 ( 见 第 67 条 )。 无 论 属于 这 其 中 的 哪 种 情况 ， 
都 可 能 会 发 生 严重 的 错误 。 


你 可 能 听 到 过 这 样 的 说 法 : 通过 查看 文档 中 是 否 出 现 synchronized 修 饰 符 ， 可 以 确定 一 个 
方法 是 否 是 线程 安全 的 。 这 种 说 法 从 几 个 方面 来 说 都 是 错误 的 。 在 正常 的 操作 中 ，Javadoc 并 
没有 在 它 的 输出 中 包含 synchronized 修 饰 符 ， 这 是 有 理由 的 。 因 为 在 一 个 方法 声明 中 出 现 
synchronized 修 饰 符 ， 这 是 个 实现 细节 ， 并 不 是 导出 的 API 的 一 部 分 。 它 并 不 一 定 表明 这 个 方 
' 法 是 线程 安全 的 。 


mH., “出现 了 synchronized 关 键 字 就 足以 用 文档 说 明 线程 安全 性 ”的 这 种 说 法 隐 含 了 一 
个 错误 的 观念 ， 即 认为 线程 安全 性 是 一 种 “要 么 全 有 要 么 全 无 ”的 属性 。 实 际 上 ， 线 程 安全 
性 有 多 种 级 别 。 一 个 类 为 了 可 被 多 个 线程 安全 地 使 用 ， 必 须 在 文档 中 清楚 地 说 明 它 所 支持 的 
线程 安全 性 级 别 。 


下 面 的 列表 概括 了 线程 安全 性 的 几 种 级 别 。 这 份 列 表 并 没有 涵盖 所 有 的 可 能 ， 而 只 是 些 党 
见 的 情形 : 


e RTE (immutable) 一 一 这 个 类 的 实例 是 不 变 的 。 所 以 ， 不 需要 外 部 的 同步 。 这 样 
的 例子 包括 String、Long 和 BigInteger ( 见 第 15 条 )。 


* 无条件 的 线程 安全 (unconditionally thread-safe) 一 一 这 个 类 的 实例 是 可 变 的， 但 是 
这 个 类 有 着 足够 的 内 部 同步 ， 所 以 ， 它 的 实例 可 以 被 并 发 使 用 ， 无 需 任何 外 部 同步 。 其 
例子 包括 Random 和 ConcurrentHashMap 。 


。 有 条 件 的 线程 安全 (conditionally thread-safe) 一 一 除了 有 些 方法 为 进行 安全 的 并 发 
使 用 而 需要 外 部 同步 之 外 ， 这 种 线程 安全 级 别 与 无 条 件 的 线程 安全 相同 。 这 样 的 例子 包 
括 Collections.synchronized 包 装 返回 的 集合 ， 它 们 的 迭代 器 (iterator) 要 求 外 部 同步 。 


* 非 线程 安全 (not thread-safe) 一 一 这 个 类 的 实例 是 可 变 的 。 为 了 并 发 地 使 用 它们 ， 客 
户 必 须 利 用 自己 选择 的 外 部 同步 包围 每 个 方法 调用 (或 者 调用 序列 ) 。 这 样 的 例子 包括 
通用 的 集合 实现 ， 例 如 ArrayList 和 HashMap。 
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。 线 程 对 立 的 (thread-hostile) 一 一 这 个 类 不 能 安全 地 被 多 个 线程 并 发 使 用 ， 即 使 所 有 的 
方法 调用 都 被 外 部 同步 包围 。 线 程 对 立 的 根源 通常 在 于 ， 没 有 同步 地 修改 静态 数据 。 没 
有 人 会 有 意 编写 一 个 线程 对 立 的 类 ， 这 种 类 是 因为 没有 考虑 到 并 发 性 而 产生 的 后 果 。 幸 
运 的 是 ， 在 Java 平 台 类 库 中 ， 线 程 对 立 的 类 或 者 方法 非常 少 。System.runFinalizersOnExit 
方法 是 线程 对 立 的 ， 但 已 经 被 废除 了 。 


这 些 分 类 (除了 线程 对 立 的 之 外 ) 粗略 对 应 于 《Java Concurrency in Practice》 一 书 中 的 
线程 安全 注解 (thread safety annotation), ， 分 别 为 Immutable、 ThreadSafe 和 NotThreadsafe 
[Goetz06, Appendix Al]。 上 述 分 类 中 无 条 件 和 有 条 件 的 线程 安全 类 别 都 涵盖 在 ThreadSafe 注 
解 中 了 。 


在 文档 中 描述 一 个 有 条 件 的 线程 安全 类 要 特别 小 心 。 你 必须 指明 哪个 调用 序列 需要 外 部 同 
步 ， 还 要 指明 为 了 执行 这 些 序 列 ， 必 须 获得 哪 一 把 锁 ( 极 少 的 情况 下 是 指 哪 几 把 锁 )。 通 常情 
况 下 ， 这 是 指 作 用 在 实例 自身 上 的 那 把 锁 ， 但 也 有 例外 。 如 果 一 个 对 象 代表 了 另 一 个 对 象 的 
一 个 视图 (view)， 客 户 通常 就 必须 在 后 台 对 象 上 同步 ， 以 防止 其 他 线程 直接 修改 后 台 对 象 。 
例如 ， Collections.synchronizedMap 的 文档 应 该 有 这 样 的 说 明 : 


It is imperative that the user manually synchronize on the returned map when 
iterating over any of its collection views: 


( 当 遍 历任 何 被 返回 Map 的 集合 视图 时 ， 用 户 必 须 手 工 对 它们 进行 同步 :) 
Map<K, V> m = Collections.synchronizedMap(new HashMap<K, V>()); 

Set<K> s = m.keySet(); // Needn't be in synchronized block 

synchronized(m) { // Synchronizing on m, not s! 


for (K key : s) 
key.fO; 
} 


如 果 没 有 遵循 这 样 的 建议 ， 就 可 能 造成 不 确定 的 行为 。 


类 的 线程 安全 说 明 通常 放 在 它 的 文档 注释 中 ， 但 是 带 有 特殊 线程 安全 属性 的 方法 则 应 该 在 
它们 自己 的 文档 注释 中 说 明 它 们 的 属性 。 没 有 必要 说 明 枚 举 类 型 的 不 可 变性 。 除 非 从 返回 类 
型 来 看 已 经 很 明显 ， 否 则 静态 工厂 必须 在 文档 中 说 明 被 返回 对 象 的 线程 安全 性 ， 如 
Collections.synchronizedMap (上 述 ) 所 示 。 


当 一 个 类 承诺 了 “使 用 一 个 公有 可 访问 的 锁 对 象 ”时 ， 就 意味 着 允许 客户 端 以 原子 的 方式 
执行 一 个 方法 调用 序列 ， 但 是 ， 这 种 灵活 性 是 要 付出 代价 的 。 并 发 集合 (如 ConcurrentHash- 
Map 和 ConcurrentLinkedQueue) 使 用 的 那 种 并 发 控制 , 并 不 能 与 高 性 能 的 内 部 并 发 控制 相 兼 容 。 
客户 端 还 可 以 发 起 拒绝 服务 (denial-of service) 攻击 ， 他 只 需 超时 地 保持 公有 可 访问 锁 即 可 。 
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这 有 可 能 是 无 意 的 ， 也 可 能 是 有 意 的 。 


为 了 避免 这 种 拒绝 服务 攻击 ， 应 该 使 用 一 个 私有 锁 对 象 (private lock object) 来 代替 同步 
的 方法 ( 隐 含 着 一 个 公有 可 访问 锁 ): 


// Private lock object idiom - thwarts denial-of-service attack 
private ‘final Object lock = new Object(); 


public void foo() { t 


synchronized(lock) { 
A AG 
} 
因为 这 个 私有 锁 对 象 不 能 被 这 个 类 的 客户 端 程序 所 访问 ， 所 以 它们 不 可 能 妨碍 对 象 的 同 
F. KRE, 我 们 正 是 在 应 用 第 13 条 的 建议 ， 把 锁 对 象 封装 在 它 所 同步 的 对 象 中 。 


注意 lock 域 被 声明 为 final 的 。 这 样 可 以 防止 不 小 心 改 变 它 的 内 容 ， 而 导致 不 同步 访问 包含 
对 象 的 悲惨 后 果 ( 见 第 66 条 ) 。 我 们 这 是 在 应 用 第 15 条 的 建议 ， 将 lock 域 的 可 变性 减 到 最 小 。 


重申 一 下 ， 私 有 锁 对 象 模式 只 能 用 在 无 条 件 的 线程 安全 类 上 。 有 条 件 的 线程 安全 类 不 能 使 
用 这 种 模式 ， 因 为 它们 必须 在 文档 中 说 明 : 在 执行 某 些 方法 调用 序列 时 ， 它 们 的 客户 端 程序 
必须 获得 哪 把 锁 。 


私有 锁 对 象 模式 特别 适用 于 那些 专门 为 继承 而 设计 的 类 ( 见 第 17 条 )。 如 果 这 种 类 使 用 它 
的 实例 作为 锁 对 象 ， 子 类 可 能 很 容易 在 无 意 中 妨碍 基 类 的 操作 ， 反 之 亦 然 。 出 于 不 同 的 目的 
而 使 用 相同 的 锁 ， 子 类 和 基 类 可 能 会 “相互 绊 住 对 方 的 脚 "。 这 不 只 是 一 个 理论 意义 上 的 问题 。 
例如 ， 这 种 现象 在 Thread 类 上 就 出 现 过 [Bloch05，Puzzle 77]。 


简 而 言 之 ， 每 个 类 都 应 该 利用 字 振 句 酌 的 说 明 或 者 线程 安全 注解 ， 清 楚 地 在 文档 中 说 明 它 
的 线程 安全 属性 。synchronized 修 饰 符 与 这 个 文档 毫 无 关系 。 有 条 件 的 线程 安全 类 必须 在 文档 
中 指明 “哪个 方法 调用 序列 需要 外 部 同步 ， 以 及 在 执行 这 些 序列 的 时 候 要 获得 哪 把 锁 ”。 如 果 
你 编写 的 是 无 条 件 的 线程 安全 类 ， 就 应 该 考虑 使 用 私有 锁 对 象 来 代替 同步 的 方法 。 这 样 可 以 
防止 客户 端 程序 和 子 类 的 不 同步 干扰 ， 让 你 能 够 在 后 续 的 版 本 中 灵活 地 对 并 发 控制 采用 更 加 
复杂 的 方法 。 





延迟 初始 化 (lazy initialization) 是 延迟 到 需要 域 的 值 时 才 将 它 初始 化 的 这 种 行为 。 如 果 
永远 不 需要 这 个 值 ， 这 个 域 就 永远 不 会 被 初始 化 。 这 种 方法 既 适 用 于 静态 域 ， 也 适用 于 实例 
域 。 虽 然 延迟 初始 化 主要 是 一 种 优化 ， 但 它 也 可 以 用 来 打破 类 和 实例 初始 化 中 的 有 害 循环 
[Bloch05, Puzzle 51], 


就 像 大 多 数 的 优化 一 样 ， 对 于 延迟 初始 化 ， 最 好 建议 “除非 绝对 必要 ， 否 则 就 不 要 这 么 做 ” 
( 见 第 55 条 )。 延 迟 初始 化 就 像 一 把 双 刃 剑 。 它 降低 了 初始 化 类 或 者 创建 实例 的 开销 ， 却 增加 
了 访问 被 延迟 初始 化 的 域 的 开销 。 根 据 延 迟 初 始 化 的 域 最 终 需 要 初始 化 的 比例 、 初 始 化 这 些 
域 要 多 少 开销 ， 以 及 每 个 域 多 久 被 访问 一 次 ， 延 迟 初 始 化 〈 就 像 其 他 的 许多 优化 一 样 ) 实际 
上 降低 了 性 能 。 


也 就 是 说 ， 延 迟 初始 化 有 它 的 好 处 。 如 果 域 只 在 类 的 实例 部 分 被 访问 ， 并 且 初 始 化 这 个 域 
的 开销 很 高 ， 可 能 就 值得 进行 延迟 初始 化 。 要 确定 这 一 点 ， 唯 一 的 办 法 就 是 测量 类 在 用 和 不 
用 延迟 初始 化 时 的 性 能 差别 。 


当 有 多 个 线程 时 ， 延 迟 初始 化 是 需要 技巧 的 。 如 果 两 个 或 者 多 个 线程 共享 一 个 延迟 初始 化 
的 域 ， 采 用 某 种 形式 的 同步 是 很 重要 的 ， 否 则 就 可 能 造成 严重 的 Bug ( 见 第 66 条 ) 。 本 条 目 中 
讨论 的 所 有 初始 化 方法 都 是 线程 安全 的 。 


在 大 多 数 情况 下 ， 正 常 的 初始 化 要 优先 于 延迟 初始 化 。 下 面 是 正常 初始 化 的 实例 域 的 一 个 
典型 声明 。 注 意 其 中 使 用 了 final 修 饰 符 ( 见 第 15 条 ): 

// Normal initialization of an instance field 

private final FieldType field = computeFieldValue(); 

如 果 利 用 延迟 优化 来 破坏 初始 化 的 循环 ， 就 要 使 用 同步 访问 方法 ， 因 为 它 是 最 简单 、 最 清 
楚 的 替代 方法 : 


// Lazy initialization of instance field - synchronized accessor 
. private FieldType field; 


synchronized FieldType getField() { 
if (field == null) 


field = computeFieldValue(); 
return field; 


这 两 种 习惯 模式 (正常 的 初始 化 和 使 用 了 同步 访问 方法 的 延迟 初始 化 ) 应 用 到 静态 域 上 时 
保持 不 变 ， 除 了 给 域 和 访问 方法 声明 添加 了 static 修 饰 符 之 外 。 
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如 果 出 于 性 能 的 考虑 而 需要 对 静态 域 使 用 延迟 初始 化 ， 就 使 用 lazy initialization holder 
class 模 式 。 这 种 模式 (也 称 作 initialize-on-demand holder class idiom) 保证 了 类 要 到 被 用 
到 的 时 候 才 会 被 初始 化 [JLS，12.4.1]。 如 下 所 示 : 


// Lazy initialization holder class idiom for static fields 
private static class FieldHolder { 
static final FieldType field = computeFieldValue(); 


} 
static FieldType getField() { return FieldHolder.field; } 


当 getField 方 法 第 一 次 被 调用 时 ， 它 第 一 次 读 取 FieldHolder.field， 导 致 FieldHolder 类 得 到 
初始 化 。 这 种 模式 的 魅力 在 于 ，getField 方 法 没有 被 同步 ， 并 且 只 执行 一 个 域 访 问 ， 因 此 延迟 
初始 化 实际 上 并 没有 增加 任何 访问 成 本 。 现 代 的 VM 将 在 初始 化 该 类 的 时 候 ， 同 步 域 的 访问 。 
一 旦 这 个 类 被 初始 化 ，VM 将 修补 代码 ， 以 便 后 续 对 该 域 的 访问 不 会 导致 任何 测试 或 者 同步 。 


如 果 出 于 性 能 的 考虑 而 需要 对 实例 域 使 用 延迟 初始 化 ， 就 使 用 双重 检查 模式 (double- 
check idiom)。 这 种 模式 避免 了 在 域 被 初始 化 之 后 访问 这 个 域 时 的 锁定 开销 ( 见 第 67 条 )。 这 
种 模式 背后 的 思想 是 : 两 次 检查 域 的 值 [因此 名 字 叫 双重 检查 (double-check) ]， 第 一 次 检查 
时 没有 锁定 ， 看 看 这 个 域 是 否 被 初始 化 了 ， 第 二 次 检查 时 有 锁定 。 只 有 当 第 二 次 检查 时 表明 
这 个 域 没 有 被 初始 化 ， 才 会 调用 computeFieldValue 方 法 对 这 个 域 进行 初始 化 。 因 为 如 果 域 已 
经 被 初始 化 就 不 会 有 锁定 ， 域 被 声明 为 volatile 很 重要 ( 见 第 66 条 ) 。 下 面 就 是 这 种 习惯 模式 ; 

// Double-check idiom for lazy initialization of instance fields 

_ Private volatile FieldType field; 
FieldType getField() { 
FieldType result = field; 
if (result == null) { // First check (no locking) 
synchronized(this) { 
result = field; 
if (result == null) // Second check (with locking) 
} field = result = computeFieldValue(); 


} 


return result; 


这 段 代码 可 能 看 起 来 似乎 有 些 费 解 。 尤 其 对 于 需要 用 到 局 部 变量 result 可 能 有 点 不 解 。 这 
个 变量 的 作用 是 确保 field 只 在 已 经 被 初始 化 的 情况 下 读 取 一 次 。 虽 然 这 不 是 严格 需要 ， 但 是 
可 以 提升 性 能 ， 并 且 因 为 给 低级 的 并 发 编程 应 用 了 一 些 标准 ， 因 此 更 加 优雅 。 在 我 的 机 器 上 ， 
上 述 的 方法 比 没 用 局 部 变量 的 方法 快 了 大 约 25%。 


在 Java 1.5 发 行 版 本 之 前 ， 双 重 检 查 模式 的 功能 很 不 稳定 ， 因 为 volatile 修 饰 符 的 语义 不 够 
强 ， 难 以 支持 它 [Pugh01] 。Java 1.5 发 行 版 本 中 引入 的 内 存 模式 解决 了 这 个 问题 [JILS，17， 
Goetz06 16]。 如 今 ， 双 重 检 查 模式 是 延迟 初始 化 一 个 实例 域 的 方法 。 虽 然 你 也 可 以 对 静态 域 
应 用 双重 检查 模式 ， 但 是 没有 理由 这 么 做 ， 因 为 ljazy initialization holder class idiom 是 更 好 的 
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选择 。 

双重 检查 模式 的 两 个 变量 值得 一 提 。 有 了 时候， 你 可 能 需要 延迟 初始 化 一 个 可 以 接受 重复 初 
始 化 的 实例 域 。 如 果 处 于 这 种 情况 ， 就 可 以 使 用 双重 检查 惯用 法 的 一 个 变形 ， 它 省 去 了 第 二 


次 检查 。 没 错 ， 它 就 是 单 重 检查 模式 (single-check idiom)。 下 面 就 是 这 样 的 一 个 例子 。 注 
意 field 仍 然 被 声明 为 volatile: 


// Single-check idiom - can cause repeated initialization! 
private volatile FieldType field; 


private FieldType getField() { 
FieldType result = field; 
if (result == null) 


field = result = computeFieldValue(); 
return result; 


本 条 目 中 讨论 的 所 有 初始 化 方法 都 适用 于 基本 类 型 的 域 ， 以 及 对 象 引用 域 。 当 双 重 检查 模 
A (double-check idiom) 或 者 单 重 检查 模式 (single-check idiom) 应 用 到 数值 型 的 基本 类 型 
域 时 ， 就 会 用 0 来 检查 这 个 域 (这 是 数值 型 基本 变量 的 默认 值 )， 而 不 是 用 null。 


如 果 你 不 在 意 是 否 每 个 线程 都 重新 计算 域 的 值 ， 并 且 域 的 类 型 为 基本 类 型 ， 而 不 是 long 或 
者 double 类 型 ， 就 可 以 选择 从 单 重 检查 模式 的 域 声明 中 删除 volatile 修 饰 符 。 这 种 变 体 称 之 为 
racy single-check idiom。 它 加 快 了 某 些 架 构 上 的 域 访问 ， 代 价 是 增加 了 额外 的 初始 化 (直到 
访问 该 域 的 每 个 线程 都 进行 一 次 初始 化 ) 。 这 显然 是 一 种 特殊 的 方法 ， 不 适合 于 日 常 的 使 用 。 
然而 ，String 实 例 却 用 它 来 缓存 它们 的 散 列 码 。 


简 而 言 之 ， 大 多 数 的 域 应 该 正常 地 进行 初始 化 ， 而 不 是 延迟 初始 化 。 如 果 为 了 达到 性 能 目 
标 ， 或 者 为 了 破坏 有 害 的 初始 化 循环 ， 而 必须 延迟 初始 化 一 个 域 ， 就 可 以 使 用 相应 的 延迟 初 
始 化 方法 。 对 于 实例 域 ， 就 使 用 双重 检查 模式 (double-check idiom) ， 对 于 静态 域 ， 则 使 用 
lazy initialization holder class idiom。 对 于 可 以 接受 重复 初始 化 的 实例 域 ， 也 可 以 考虑 使 用 单 
重 检查 模式 (single-check idiom), 





当 有 多 个 线程 可 以 运行 时 ， 由 线程 调度 器 (thread scheduler) 决定 哪些 线程 将 会 运行 ， 
以 及 运行 多 长 时 间 。 任 何 一 个 合理 的 操作 系统 在 做 出 这 样 的 决定 时 ， 都 会 努力 做 到 公正 ， 但 
是 所 采用 的 策略 却 大 相 径 庭 。 因 此 ， 编 写 良 好 的 程序 不 应 该 依赖 于 这 种 策略 的 细节 。 任 何 依 
赖 于 线程 调度 器 来 达到 正确 性 或 者 性 能 要 求 的 程序 ， 很 有 可 能 都 是 不 可 移植 的 。 


要 编写 健壮 的 、 响 应 良好 的 、 可 移植 的 多 线程 应 用 程序 ， 最 好 的 办 法 是 确保 可 运行 线程 的 
平均 数量 不 明显 多 于 处 理 器 的 数量 。 这 使 得 线程 调度 器 没有 更 多 的 选择 : 它 只 需要 运行 这 些 
可 运行 的 线程 ， 直 到 它们 不 再 可 运行 为 止 。 即 使 在 根本 不 同 的 线程 调度 算法 下 ， 这 些 程序 的 
行为 也 不 会 有 很 大 的 变化 。 注 意 可 运行 线程 的 数量 并 不 等 于 线程 的 总 数量 ， 前 者 可 能 更 多 。 
在 等 待 的 线程 并 不 是 可 运行 的 。 


保持 可 运行 线程 数量 尽 可 能 少 的 主要 方法 是 ， 让 每 个 线程 做 些 有 意义 的 工作 ， 然 后 等 待 更 
多 有 意义 的 工作 。 如 果 线 程 没有 在 做 有 意义 的 工作 ， 就 不 应 该 运行 。 根 据 Executor Framework 
( 见 第 68 条 ) ， 这 意味 着 适当 地 规定 了 线程 池 的 大 小 [Goetz06 8.2]， 并 且 使 任务 保持 适当 地 小 ， 
彼此 独立 。 任 务 不 应 该 太 小 ， 否 则 分 配 的 开销 也 会 影响 到 性 能 。 


线程 不 应 该 一 直 处 于 忙 一 等 (busy-wait) 的 状态 ， 即 反复 地 检查 一 个 共享 对 象 ， 以 等 待 
某 些 事情 发 生 。 除 了 使 程序 易 受 到 调度 器 的 变化 影响 之 外 ， 忙 -等 这 种 做 法 也 会 极 大 地 增加 
处 理 器 的 负担 ， 降 低 了 同一 机 器 上 其 他 进程 可 以 完成 的 有 用 工作 量 。 作 为 一 个 极端 的 反面 例 
子 ， 考 虑 下 面 这 个 CountDownLatch 的 不 正当 的 重新 实现 : 


// Awful CountDownLatch implementation - busy-waits incessantly! 
public class SlowCountDownLatch { 
private int count; 
public SlowCountDownLatch(int count) { 
if (count < @) 
throw new IllegalArgumentException(count + " < 0"); 
this.count = count; 


public void await() { 
while (true) { 
synchronized(this) { 
if (count == 0) return; 


} 
} 
public synchronized void countDown() { 
if (count != 0) 
count--; 
$ 
} 


在 我 的 机 器 上 ， 当 1000 个 线程 在 锁 存 器 (latch) 中 等 待 的 时 候 ，SlowCountDownLatch 比 
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CountDownLatch 慢 了 大 约 2000 倍 。 虽 然 这 个 例子 可 能 显得 有 点 牵强 ， 但 是 系统 中 有 一 个 或 者 
多 个 线程 处 于 不 必要 的 可 运行 状态 ， 这 种 现象 并 不 少见 。 结 果 虽 然 不 像 SlowCountDownLatch 
那么 悲惨 ， 但 是 性 能 和 可 移植 性 都 可 能 受到 损害 。 


如 果 某 一 个 程序 不 能 工作 ， 是 因为 某 些 线程 无 法 像 其 他 线程 那样 获得 足够 的 CPU 时 间 ， 那 
么 ， 不 要 企图 通过 调用 Thread.yield 来 “修正 ”该 程序 。 你 可 能 好 不 容易 成 功 地 让 程序 能 够 工 
作 ， 但 这 样 得 到 的 程序 仍然 是 不 可 移植 的 。 同 一 个 yield 调 用 在 一 个 JVM 实 现 上 能 提高 性 能 ， 
而 在 另 一 个 JVM 实 现 上 却 有 可 能 会 更 差 ， 在 第 三 个 JVM 实 现 上 则 可 能 没有 影响 。Thread.yield 
没有 可 测试 的 语义 (testable semantic) 。 更 好 的 解决 办 法 是 重新 构造 应 用 程序 ， 以 减少 可 并 发 
运行 的 线程 数量 。 


有 一 种 相关 的 方法 是 调整 线程 优先 级 (thread priority) ， 同 样 有 类 似 的 警告 。 线 程 优先 级 
是 Java 平 台 上 最 不 可 移植 的 特征 了 。 通 过 调整 某 些 线程 的 优先 级 来 改善 应 用 程序 的 响应 能 力 ， 
这 样 做 并 非 不 合理 ， 却 是 不 必要 的 ， 也 是 不 可 移植 的 。 通 过 调整 线程 的 优先 级 来 解决 严重 的 
活性 问题 是 不 合理 的 。 在 你 找到 并 修正 底层 的 真正 原因 之 前 ， 这 个 问题 可 能 会 再 次 出 现 。 


在 本 书 第 一 版 中 说 过 ， 对 于 大 多 数 程序 员 来 说 ，Thread.yield 的 唯一 用 途 是 在 测试 期 间 人 
为 地 增加 程序 的 并 发 性 。 意 思 就 是 ， 通 过 探查 程序 中 更 大 部 分 的 状态 空间 ， 可 以 发 现 一 些 隐 
项 的 Bug。 这 种 方法 曾经 十 分 奏效 ,但 从 来 不 能 保证 一 定 可 行 。 在 Java 语 言 规范 中 ， 
Thread.yield 根 本 不 做 实质 性 的 工作 ， 只 是 将 控制 权 返 回 给 它 的 调用 者 。 有 些 现代 的 VM 实际 
上 正 是 这 种 功能 。 因 此 ， 应 该 使 用 Thread.sleep(1) 代 替 Thread.yield 来 进行 并 发 测试 。 千 万 不 
要 使 用 Thread.sleep(0)， 它 会 立即 返回 。 


简 而 言 之 ， 不 要 让 应 用 程序 的 正确 性 依赖 于 线程 调度 器 。 否 则 ， 结 果 得 到 的 应 用 程序 将 既 
不 健壮 ， 也 不 具有 可 移植 性 。 作 为 推论 ， 不 要 依赖 Thread.yield 或 者 线程 优先 级 。 这 些 设施 仅 
仅 对 调度 器 作 些 上 暗示。 线程 优先 级 可 以 用 来 提高 一 个 已 经 能 够 正常 工作 的 程序 的 服务 质量 ， 
但 永远 不 应 该 用 来 “修正 ”一 个 原本 并 不 能 工作 的 程序 。 





除了 线程 、 锁 和 监视 器 之 外 ， 线 程 系统 还 提供 了 一 个 基本 的 抽象 ， 即 线程 组 (thread 
group ) 。 线 程 组 的 初衷 是 作为 一 种 隔离 applet (小 程序 ) 的 机 制 ， 当 然 是 出 于 安全 的 考虑 。 但 
是 它们 从 来 没有 真正 履行 这 个 承诺 ， 它 们 的 安全 价值 已 经 差 到 根本 不 在 Java 安 全 模型 的 标准 工 
作 中 提 及 的 地 步 [Gong03] 。 


既然 线程 组 并 没有 提供 所 提 及 的 任何 安全 功能 ， 那 么 它们 到 底 提供 了 什么 功能 呢 ? 不 多 。 
它们 允许 你 同时 把 Thread 的 某 些 基本 功能 应 用 到 一 组 线程 上 。 其 中 有 一 些 基本 功能 已 经 被 废 
弃 了 ， 剩 下 的 也 很 少 使 用 。 


具有 讽刺 意味 的 是 ， 从 线程 安全 性 的 角度 来 看 ，ThreadGroup API 非 常 弱 。 为 了 得 到 一 个 
线程 组 中 的 活动 线程 列表 ， 你 必须 调用 enumerate 方 法 ， 它 有 一 个 数组 参数 ， 并 且 数 组 的 容量 
必须 足够 大 ， 以 便 容纳 所 有 的 活动 线程 。activeCount 方 法 返回 一 个 线程 组 中 活动 线程 的 数量 ， 
但 是 ， 一旦 这 个 数组 进行 了 分 配 ， 并 传递 给 了 enumerate 方 法 ， 就 不 保证 原先 得 到 的 活动 线程 
数 仍 是 正确 的 。 如 果 线 程 数 增加 了 ， 而 数组 太 小 ，enumerate 方 法 就 会 悄然 地 忽略 掉 无 法 在 数 
组 中 容纳 的 线程 。 


列 出 线程 组 中 子 组 的 API 也 有 类 似 的 缺陷 。 虽 然 通过 增加 新 的 方法 、 这些 问题 都 有 可 能 得 
到 修正 ， 但 是 ， 它 们 目前 还 没有 被 修正 ， 因 为 线程 组 已 经 过 时 了 ， 所 以 实际 上 根本 没有 必要 
修正 。 


在 Java 1.5 发 行 版 本 之 前 ， 有 一 种 小 功能 只 有 ThreadGroup API 才 有 : 当 线 程 抛 出 未 被 捕 
捉 的 异常 时 ，ThreadGroup.uncaughtException 方 法 是 获得 控制 权 的 唯一 方式 。 这 项 功能 很 有 
用 ， 例 如 ， 为 了 把 堆栈 轨迹 定向 到 一 个 特定 于 应 用 程序 的 日 志 中 。 然 而 ， 自 从 Java 1.5 发 行 版 
本 之 后 ，Thread 的 setUncaughtExceptionHandler 方 法 也 提供 了 同样 的 功能 。 


总 而 言 之 , 线程 组 并 没有 提供 太 多 有 用 的 功能 , 而 且 它 们 提供 的 许多 功能 还 都 是 有 缺陷 的 。 
我 们 最 好 把 线程 组 看 作 是 一 个 不 成 功 的 试验 ， 你 可 以 忽略 掉 它们 ， 就 当 它 们 根本 不 存在 一 样 。 
如 果 你 正在 设计 的 一 个 类 需要 处 理 线程 的 逻辑 组 ,或 许 就 应 该 使 用 线程 池 executor( 见 第 68 条 ) 。 





第 11 章 


序列 化 


本 章 关 注 对 象 序列 化 (object serialization) API， 它 提供 了 一 个 框架 ， 用 来 将 对 象 纺 
码 成 字 节 流 ， 并 从 字 节 流 编码 中 重新 构建 对 象 。“ 将 一 个 对 象 编码 成 一 个 字 节 流 ”， 称 作 将 该 
对 象 序列 化 (serializing) ， 相 反 的 处 理 过 程 被 称 作 反 序列 化 (deserializing)。 一 旦 对 象 被 
序列 化 后 ， 它 的 编码 就 可 以 从 一 台 正 在 运行 的 虚拟 机 被 传递 到 另 一 台 虚 拟 机 上 ， 或 者 被 存储 
到 磁盘 上 ， 供 以 后 反 序列 化 时 用 。 序 列 化 技术 为 远程 通信 提供 了 标准 的 线路 级 (wire-level) 
对 象 表示 法 ， 也 为 JavaBeans 组 件 结构 提供 了 标准 的 持久 化 数据 格式 。 本 章 中 有 一 项 值得 特别 
提 及 的 特性 ， 就 是 序列 化 代理 (serialization proxy) 模式 ( 见 第 78 条 )， 它 可 以 帮助 你 避免 
对 象 序列 化 的 许多 缺陷 。 





要 想 使 一 个 类 的 实例 可 被 序列 化 ,非常 简单 ， 只 要 在 它 的 声明 中 加 入 “implements 
Serializable” 字 样 即 可 。 正 因为 太 容易 了 ， 所 以 普遍 存在 这 样 一 种 误解 ， 认 为 程序 员 毫 不 费 
力 就 可 以 实现 序列 化 。 实 际 的 情形 要 复杂 得 多 。 虽 然 使 一 个 类 可 被 序列 化 的 直接 开销 非常 低 ， 
甚至 可 以 忽略 不 计 ， 但 是 为 了 序列 化 而 付出 的 长 期 开销 往往 是 实 实在 在 的 。 


实现 Serializable 接 口 而 付出 的 最 大 代价 是 ,一旦 一 个 类 被 发 布 ， 就 大 大 降低 了 “改变 
这 个 类 的 实现 ”的 灵活 性 。 如 果 一 个 类 实现 了 Serializable 接 口 ， 它 的 字 节 流 编码 (或 者 说 
序列 化 形式 ，serialized form) 就 变 成 了 它 的 导出 的 API 的 一 部 分 。: 一 旦 这 个 类 被 广泛 使 用 ， 
往往 必须 永远 支持 这 种 序列 化 形式 ， 就 好 像 你 必须 要 支持 导出 的 API 的 所 有 其 他 部 分 一 样 。 
如 果 你 不 努力 设计 一 种 自 定义 的 序列 化 形式 (custom serialized form) ， 而 仅仅 接受 了 默认 
的 序列 化 形式 ， 这 种 序列 化 形式 将 被 永远 地 束缚 在 该 类 最 初 的 内 部 表示 法 上。 换 甸 话说 ， 如 
果 你 接受 了 默认 的 序列 化 形式 ， 这 个 类 中 私有 的 和 包 级 私有 的 实例 域 将 都 变 成 导出 的 API 的 
一 部 分 ， 这 不 符合 “最 低 限度 地 访问 域 ” 的 实践 准则 ( 见 第 13 条 ) ， 从 而 它 就 失去 了 作为 信 
息 隐藏 工具 的 有 效 性 。 
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如 果 你 接受 了 默认 的 序列 化 形式 ， 并 且 以 后 又 要 改变 这 个 类 的 内 部 表示 法 ， 结 果 可 能 导致 
序列 化 形式 的 不 兼容 。 客 户 端 程序 企图 用 这 个 类 的 旧版 本 来 序列 化 一 个 类 ， 然 后 用 新 版 本 进 
行 反 序列 化 ， 结 果 将 导致 程序 失败 。 在 改变 内 部 表示 法 的 同时 仍然 维持 原来 的 序列 化 形式 
(使 用 ObjectOutputStream.putFields 和 ObjectInputStream.readFields) ， 这 也 是 可 能 的 ， 但 是 做 
起 来 比较 困难 ， 并 且 会 在 源 代码 中 留 下 一 些 明显 的 隐患 。 因 此 ， 你 应 该 仔细 地 设计 一 种 高 质 
量 的 序列 化 形式 ， 并 且 在 很 长 时 间 内 都 愿意 使 用 这 种 形式 ( 见 第 75，78 条 )。 这 样 做 将 会 增加 
开发 的 初始 成 本 ， 但 这 是 值得 的 。 设 计 良 好 的 序列 化 形式 也 许 会 给 类 的 演变 带 来 限制 ， 但 是 
设计 不 好 的 序列 化 形式 则 可 能 会 使 类 根本 无 法 演变 。 


序列 化 会 使 类 的 演变 受到 限制 ， 这 种 限制 的 一 个 例子 与 流 的 唯一 标识 符 (stream unique 
identifier) 有 关 ， 通常 它 也 被 称 为 序列 版 本 UID (serial version UID ) 。 每 个 可 序列 化 的 类 都 
有 一 个 唯一 标识 号 与 它 相 关联 。 如 果 你 没有 在 一 个 名 为 serialVersionUID 的 私有 静态 final 的 
long 域 中 显 式 地 指定 该 标识 号 ， 系 统 就 会 自动 地 根据 这 个 类 来 调用 一 个 复杂 的 运算 过 程 ， 从 而 
在 运行 时 产生 该 标识 号 。 这 个 自动 产生 的 值 会 受到 类 名 称 、 它 所 实现 的 接口 的 名 称 、 以 及 所 有 
公有 的 和 受 保护 的 成 员 的 名 称 所 影响 。 如 果 你 通过 任何 方式 改变 了 这 些 信息 ， 比 如 ， 增 加 了 一 
个 不 是 很 重要 的 工具 方法 ， 自 动产 生 的 序列 版 本 UID 也 会 发 生变 化 。 因 此 ， 如 果 你 没有 声明 一 
个 显 式 的 序列 版 本 UID， 兼容 性 将 会 遭 到 破坏 ， 在 运行 时 导致 InvalidClassException 异 常 。 


实现 Serializable 的 第 二 个 代价 是 ， 它 增加 了 出 现 Bug 和 安全 漏洞 的 可 能 性 。 通 常情 况 下 ， 
对 象 是 利用 构造 器 来 创建 的 ， 序列 化 机 制 是 一 种 语言 之 外 的 对 象 创建 机 制 (extralinguistic 
mechanism)。 无 论 你 是 接受 了 默认 的 行为 ， 还 是 覆盖 了 上 默认 的 行为 ， 反 序列 化 机 制 
(deserialization) 都 是 一 个 “隐藏 的 构造 器 " ， 具 备 与 其 他 构造 器 相同 的 特点 。 因 为 反 序 列 化 机 制 
中 没有 显 式 的 构造 器 ， 所 以 你 很 容易 忘记 要 确保 : 反 序 列 化 过 程 必 须 也 要 保证 所 有 “由 真正 的 构 
造 器 建立 起 来 的 约束 关系 ”， 并 且 不 允许 攻击 者 访问 正在 构造 过 程 中 的 对 象 的 内 部 信息 。 依 靠 默 
认 的 反 序 列 化 机 制 ， 很 容易 使 对 象 的 约束 关系 遭 到 破坏 ， 以 及 遭受 到 非法 访问 ( 见 第 76 条 )。 


实现 Serializable 的 第 三 个 代价 是 ， 随 着 类 发 行 新 的 版 本 ， 相 关 的 测试 负担 也 增加 了 。 当 
一 个 可 序列 化 的 类 被 修订 的 时 候 ， 很 重要 的 一 点 是 ， 要 检查 是 否 可 以 “在 新 版 本 中 序列 化 一 
个 实例 ， 然 后 在 旧版 本 中 反 序 列 化 "， 反 之 亦 然 。 因 此 ， 测 试 所 需要 的 工作 量 与 “可 序列 化 的 
类 的 数量 和 发 行 版 本 号 ”的 乘积 成 正比 ， 这 个 乘积 可 能 会 非常 大 。 这 些 测试 不 可 能 自动 构建 ， 
因为 除了 二 进 制 兼容 性 (binary compatibility) 以 外 ， 你 还 必须 测试 语义 兼容 性 (semantic 
compatibility)。 换 句 话 说 ， 你 必须 既 要 确保 “序列 化 一 反 序列 化 ”过 程 成 功 ， 也 要 确保 结果 
产生 的 对 象 真正 是 原始 对 象 的 复制 品 。 可 序列 化 类 的 变化 越 大 ， 它 就 越 需 要 测试 。 如 果 在 最 
初 编写 一 个 类 的 时 候 ， 就 精心 设计 了 自 定义 的 序列 化 形式 ， 测 试 的 要 求 就 可 以 有 所 降低 ， 但 
是 也 不 能 完全 没有 测试 。 


实现 Serializable 接 口 并 不 是 一 个 很 轻松 就 可 以 做 出 的 决定 。 它 提供 了 一 些 实在 的 益处 : 
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如 果 一 个 类 将 要 加 入 到 某 个 框架 中 ， 并 且 该 框架 依赖 于 序列 化 来 实现 对 象 传输 或 者 持久 化 ， 
对 于 这 个 类 来 说 ， 实 现 Serializable 接 口 就 非常 有 必要 。 更 进一步 来 看 ， 如 果 这 个 类 要 成 为 另 
一 个 类 的 一 个 组 件 ， 并 且 后 者 必须 实现 Serializable 接 口 ， 若 前 者 也 实现 了 Serializable 接 口 ， 
它 就 会 更 易于 被 后 者 使 用 。 然 而 ， 有 许多 实际 的 开销 都 与 实现 Serializable 接 口 有 关 。 每 当 你 
实现 一 个 类 的 时 候 ， 都 需要 权衡 一 下 所 付出 的 代价 和 带 来 的 好 处 。 根 据 经 验 ， 比如 Date 和 
BigInteger 这 样 的 值 类 应 该 实现 Serializable, 大 多 数 的 集合 类 也 应 该 如 此 。 代 表 活 动 实体 的 类 ， 
比如 线程 地 (thread pool), 一 般 不 应 该 实现 Serializable 。 


为 了 继承 而 设计 的 类 ( 见 第 17 条 ) 应 该 尽 可 能 少 地 去 实现 Serializable 接 口 , 用 户 的 接口 也 
应 该 尽 可 能 少 地 继承 Serializable 接 口 。 如 果 违 反 了 这 条 规则 ， 扩 展 这 个 类 或 者 实现 这 个 接口 的 程 
序 员 就 会 背 上 沉重 的 负担 。 然 而 在 有 些 情况 下 违反 这 条 规则 却 是 合适 的 。 例 如 ， 如 果 一 个 类 或 者 
接口 存在 的 目的 主要 是 为 了 参与 到 某 个 框架 中 ， 该 框架 要 求 所 有 的 参与 者 都 必须 实现 Serializable 
接口 ， 那 么 ， 对 于 这 个 类 或 者 接口 来 说 ， 实现 或 者 扩展 Serializable 接 口 就 是 非常 有 意义 的 。 


在 为 了 继承 而 设计 的 类 中 ， 真 正 实现 了 Serializable 接 口 的 有 Throwable 类 、Component 和 
HttpServjlet 抽 象 类 。 因 为 Throwable 类 实现 了 Serializable 接 口 ， 所 以 RMI 的 异常 可 以 从 服务 器 
端 传 到 客户 端 。Component 实 现 了 Serializable 接 口 ， 因 此 GUI 可 以 被 发 送 、 保 存 和 恢复 。 
HttpServlet 实 现 了 Serializable 接 口 ， 因 此 会 话 状态 (session state) 可 以 被 缓存 。 


如 果 你 实现 了 一 个 带 有 实例 域 的 类 ， 它 是 可 序列 化 和 可 扩展 的 ， 你 就 应 该 担心 这 样 一 条 告 
诚 。 如 果 类 有 一 些 约束 条 件 ， 当 类 的 实例 域 被 初始 化 成 它们 的 默认 值 (整数 类 型 为 0，boolean 
为 false， 对 象 引 用 类 型 为 null) 时 ， 就 会 违背 这 些 约束 条 件 ， 这 时 候 你 就 必须 给 这 个 类 添加 这 
个 readObjectNoData 方 法 ， 

// read0bjectNoData for stateful extendable serializable classes 

private void readObjectNoData() throws InvalidObjectException { 

throw new InvalidObjectException("Stream data required"); 

Java 1.4 的 版 本 中 就 增加 了 这 个 readObjectrNoData 方 法 ， 还 包含 了 一 些 冷 全 的 用 例 ， 包 括 

给 现 有 的 可 序列 化 类 添加 可 序列 化 的 超 类 。 如 果 你 有 兴趣 ， 可 以 在 序列 化 规范 中 找到 详细 的 
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有 一 条 告诫 与 “不 要 实现 Serializable 接 口 ” 有 关 。 如 果 一 个 专门 为 了 继承 而 设计 的 类 不 
是 可 序列 化 的 ， 就 不 可 能 编写 出 可 序列 化 的 子 类 。 特 别 是 ， 如 果 超 类 没有 提供 可 访问 的 无 参 
构造 器 ， 子 类 也 不 可 能 做 到 可 序列 化 。 因 此 ， 对 于 为 继承 而 设计 的 不 可 序列 化 的 类 ， 你 应 该 
考虑 提供 一 个 无 参 构 造 器 。 这 通常 并 不 需要 付出 特别 的 努力 ， 因 为 许多 为 继承 而 设计 的 类 都 
不 具有 状态 ， 但 是 情况 并 不 总 是 这 样 的 。 


CO Java 序列 化 规范 的 地 址 为 ， http://java.sun.com/jzse/1.5/pdf/serial-1.5.0.pdfa¢http://java.sun.com/javase/6/docs/ 
platform/serialization/spec/serialToc.heml ,: 一 一 译 者 注 
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最 好 在 所 有 的 约束 关系 都 已 经 建立 的 情况 下 再 创建 对 象 ( 见 第 15 条 )。 如 果 为 了 建立 这 些 
约束 关系 而 要 求 客 户 端 提供 一 些 数据 ， 这 实际 上 就 排除 了 使 用 无 参 构造 器 的 可 能 性 。 盲 目地 
为 一 个 类 增加 无 参 构造 器 和 单独 的 初始 化 方法 ， 而 它 的 约束 关系 仍 由 其 他 的 构造 器 来 建立 ， 
这 样 做 会 使 该 类 的 状态 空间 更 加 复杂 ， 并 且 增 加 出 错 的 可 能 性 。 


有 一 种 办 法 可 以 给 “不 可 序列 化 但 可 扩展 的 类 ”增加 无 参 构造 器 ， 同 时 避免 以 上 的 不 足 。 
假设 该 类 有 这 样 一 个 构造 器 : 


public AbstractFoo(int x, int y) { ... } 


下 面 的 转换 增加 了 一 个 受 保护 的 无 参 构造 器 ， 和 一 个 初始 化 方法 。 初 始 化 方法 与 正常 的 构 
造 器 有 具有 相同 的 参数 ， 并 且 也 建立 起 同样 的 约束 关系 。 注 意 保存 对 象 状 态 (x 和 y) 的 变量 不 
能 是 final 的 ， 因 为 它们 是 由 initialize 方 法 设置 的 : 


// Nonserializable stateful class allowing serializable subclass 
public abstract class AbstractFoo { 
private int x, y; // Our state 


// This enum and field are used to track initialization 
private enum State { NEW, INITIALIZING, INITIALIZED }; 
private final AtomicReference<State> init = 

new AtomicReference<State>(State.NEW); 


public AbstractFoo(int x, int y) { initialize(x, y); } 


// This constructor and the following method allow 
// subclass's readObject method to initialize our state. 
protected AbstractFoo() { } 
protected final void initializeCint x, int y) { 
if Clinit.compareAndSet(State.NEW, State. INITIALIZING) ) 
throw new IllegalStateException( 
"Already initialized"); 
this.x = x; 
this.y = y; 
... // Do anything else the original constructor did 
init.set(State. INITIALIZED) ; 
TER 


// These methods provide access to internal state so it can 
// be manually serialized by subclass's write0bject method. 
protected final int getX() { checkInit(); return x; } 
protected final int getY() { checkInit(); return y; } 
// Must call from all public and protected instance methods 
private void checkInitQ { 
if Cinit.getQ) != State. INITIALIZED) 
throw new IllegalStateException("Uninitialized") ; 


... // Remainder omitted 


AbstractFoo 中 所 有 公有 的 和 受 保 护 的 实例 方法 在 开始 做 任何 其 他 工作 之 前 都 必须 先 调 用 
checkInit。 这 样 可 以 确保 如 果 有 编写 不 好 的 子 类 没有 初始 化 实例 ， 该 方法 调用 就 可 以 快速 而 
干净 地 失败 。 注 意 init 域 是 一 个 原子 引用 (atomic reference) (java.util. concurrent.atomic. 
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AtomicReference)。 在 遇 到 特定 的 情况 时 ， 确 保 对 象 的 完整 性 是 很 有 必要 的 。 如 果 没 有 这 样 
的 防范 机 制 ， 万 一 有 个 线程 要 在 某 一 个 实例 上 调用 initialize， 而 另 一 个 线程 又 要 企图 使 用 这 个 
实例 ， 第 二 个 线程 就 有 可 能 看 到 这 个 实例 处 于 不 一 致 的 状态 。 这 种 模式 利用 compareAndSet 方 
法 来 操作 枚 举 的 原子 引用 ， 这 是 一 个 很 好 的 线程 安全 状态 机 (thread-safe state machine) 的 
通用 实现 。 如 果 有 了 这 样 的 机 制 做 保证 ， 实 现 一 个 可 序列 化 的 子 类 就 非常 简单 明了 ， 
// Serializable subclass of nonserializable stateful class 
public class Foo extends AbstractFoo implements Serializable { 
private void readObject(ObjectInputStream s) 
throws IOException, ClassNotFoundException { 
s.defaultReadObject(); 
// Manually deserialize and initialize superclass state 
int x = s.readInt(); 
int y = s.readInt(); 
initialize(x, y); 
} 
private void writeObject(ObjectOutputStream s) 
throws IOException { 
s.defaultWriteObject(); 
// Manually serialize superclass state 


s.writeInt(getx()); 
s.writeInt(getY(Q)); 


// Constructor does not use the fancy mechanism 
public FooCint x, int y) { super(x, y); } 


private static final long serialVersionUID = 1856835860954L; . 
} 


内 部 类 (inner class) ( 见 第 22 条 ) 不 应 该 实现 Serializable。 它们 使 用 编译 器 产生 的 合成 
域 (synthetic field) 来 保存 指向 外 围 实 例 (enclosing instance) 的 引用 ， 以 及 保存 来 自 外 转 
作用 域 的 局 部 变量 的 值 。“ 这 些 域 如 何 对 应 到 类 定义 中 ”并 没有 明确 的 规定 ， 就 好 像 没 有 指定 
匿名 类 和 局 部 类 的 名 称 一 样 。 因 此 ， 内 部 类 的 默认 序列 化 形式 是 定义 不 清楚 的 。 然 而 ， 静 态 
成 员 类 (static member class) 却 可 以 实现 Serializable 接 口 。 


简 而 言 之 ， 千 万 不 要 认为 实现 Serializable 接 口 会 很 容易 。 除非 一 个 类 在 用 了 一 段 时 间 之 
后 就 会 被 抛弃 ， 否 则 ， 实 现 Serializable 接 口 就 是 个 很 严肃 的 承诺 ， 必 须 认真 对 待 。 如 果 一 个 
类 是 为 了 继承 而 设计 的 ， 则 更 加 需要 加 倍 小 心 。 对 于 这 样 的 类 而 言 ， 在 “允许 子 类 实现 
Serializable 接 口 ” 或 “禁止 子 类 实现 Serializable 接 口 ” 两 者 之 间 的 一 个 折衷 设计 方案 是 ， 提 
供 一 个 可 访问 的 无 参 构造 器 。 这 种 设计 方案 允许 (但 不 要 求 ) 子 类 实现 Serializable 接 口 。 
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当 你 在 时 间 紧 迫 的 情况 下 设计 一 个 类 时 ， 一 般 合理 的 做 法 是 把 工作 重心 集中 在 设计 最 佳 的 
API 上 。 有 了 时候 ， 这 意味 着 要 发 行 一 个 “用 完 后 即 丢弃 ”的 实现 ， 因 为 你 知道 以 后 会 在 新 版 本 
中 将 它 替换 掉 。 正 常情 况 下 ， 这 不 成 问题 但是， 如 果 这 个 类 实现 了 Serializable 接 口 ， 并 且 
使 用 了 默认 的 序列 化 形式 ， 你 就 永远 无 法 彻底 摆脱 那个 应 该 丢弃 的 实现 了 。 它 将 永远 牵制 住 
这 个 类 的 序列 化 形式 。 这 不 只 是 一 个 纯 理 论 的 问题 ， 在 Java 平 台 类 库 中 已 经 有 几 个 类 出 现 了 这 
样 的 问题 ， 比 如 BigInteger。 


如 果 没 有 先 认 真 考虑 默认 的 序列 化 形式 是 否 合适 ， 则 不 要 贸然 接受 。 接 受 默认 的 序列 化 形 
式 是 一 个 非常 重要 的 决定 ， 你 需要 从 灵活 性 、 性 能 和 正确 性 多 个 角度 对 这 种 编码 形式 进行 考 
察 。 一 般 来 讲 ， 只 有 当 你 自行 设计 的 自 定义 序列 化 形式 与 默认 的 序列 化 形式 基本 相同 时 ， 才 
能 接受 默认 的 序列 化 形式 。 


考虑 以 一 个 对 象 为 根 的 对 象 图 ， 相 对 于 它 的 物理 表示 法 而 言 ， 该 对 象 的 默认 序列 化 形式 是 
一 种 比较 有 效 的 编码 形式 。 换 名 话说， 默认 的 序列 化 形式 描述 了 该 对 象 内 部 所 包含 的 数据 ， 
以 及 每 一 个 可 以 从 这 个 对 象 到 达 的 其 他 对 象 的 内 部 数据 。 它 也 描述 了 所 有 这 些 对 象 被 链接 起 
来 后 的 拓扑 结构 。 对 于 一 个 对 象 来 说 ， 理 想 的 序列 化 形式 应 该 只 包含 该 对 象 所 表示 的 逻辑 数 
据 ， 而 逻辑 数据 与 物理 表示 法 应 该 是 各 自 独立 的 。 


如 果 一 个 对 象 的 物理 表示 法 等 同 于 它 的 逻辑 内 容 ， 可 能 就 适合 于 使 用 默认 的 序列 化 形式 。 
例如 ， 对 于 下 面 这 些 仅仅 表示 人 名 的 类 ， 上 默认 的 序列 化 形式 就 是 合理 的 : 


// Good candidate for default serialized form 
public class Name implements Serializable { 
[ae 
+ Last name. Must be non-null. 
* @serial 


*/ 
private final String lastName; 
[rr 
* First name. Must be non-null. 
+ @serial 
*/ 
private final String firstName; 
[ra 
* Middle name, or null if there is none. 
* @serial 
*/ 
private final String middleName; 


... // Remainder omitted 


从 逻辑 的 角度 而 言 ， 一 个 名 字 包 含 三 个 字符 串 ， 分 别 代 表 姓 、 名 和 中 间 名 。Name 中 的 实 
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例 域 精确 地 反映 了 它 的 逻辑 内 容 。 


即使 你 确定 了 默认 的 序列 化 形式 是 合适 的 ， 通 常 还 必须 提供 一 个 readObject 方 法 以 保证 
约束 关系 和 安全 性 。 对 于 Name 这 个 类 而 言 ，readObject 方 法 必须 确保 lastrName 和 firstrName 是 
非 null 的 。 第 76 条 和 第 78 条 将 详细 地 讨论 这 个 问题 。 


注意 ， 虽 然 lastrName、firstName 和 middlelInitial 域 是 私有 的 ， 但 是 它们 仍然 有 相应 的 注释 
文档 。 这 是 因为 ， 这 些 私有 域 定义 了 一 个 公有 的 API， 即 这 个 类 的 序列 化 形式 ， 并 且 该 公有 的 
API 必 须 建立 文档 。@serial 标 签 告诉 Javadoc 工 具 ， 把 这 些 文档 信息 放 在 有 关 序 列 化 形式 的 特 
殊 文档 页 中 。 


FSS Nome + SA ere nee ae ane ee 
略 关于 “最 好 使 用 标准 类 库 中 List 实 现 ”的 建议 ) : 

// Awful candidate for default serialized form 
public final class StringList implements Serializable { 

private int size = 0; 

private Entry head = null; 

private static class Entry implements Serializable { 

String data; 


Entry next; 
Entry previous; 


.. // Remainder omitted 


从 逻辑 意义 上 讲 ， 这 个 类 表示 了 一 个 字符 串 序列 。 但 是 从 物理 意义 上 讲 ， 它 把 该 序列 表示 
成 一 个 双向 链表 。 如 果 你 接受 了 默认 的 序列 化 形式 ,该 序列 化 形式 将 不 遗 余力 地 镜像 出 
(mirror) 链表 中 的 所 有 项 ， 以 及 这 些 项 之 间 的 所 有 双向 链接 。 


当 一 个 对 象 的 物理 表示 法 与 它 的 还 辑 数据 内 容 有 实质 性 的 区 别 时 ， 使 用 默认 序列 化 形式 会 
有 以 下 4 个 缺点 : 


. 它 使 这 个 类 的 导出 API 永 远 地 束 缚 在 该 类 的 内 部 表示 法 上 。 在 上 面 的 例子 中 ， 私 有 的 
StringList.Entry 类 变 成 了 公有 API 的 一 部 分 。 如 果 在 将 来 的 版 本 中 ， 内 部 表示 法 发 生 了 
变化 ，StringList 类 仍 将 需要 接受 链表 形式 的 输入 ， 并 产生 链表 形式 的 输出 。 这 个 类 永远 
也 摆脱 不 掉 维 护 链表 项 所 需要 的 所 有 代码 ， 即 使 它 不 再 使 用 链表 作为 内 部 数据 结构 了 ， 
也 仍然 需要 这 些 代码 。 


. 它 会 消耗 过 多 的 空间 。 在 上 面 的 例子 中 ， 序 列 化 形式 既 表 示 了 链表 中 的 每 个 项 ， 也 表示 
了 所 有 的 链接 关系 ， 这 是 不 必要 的 。 这 些 链表 项 以 及 链接 只 不 过 是 实现 细节 ， 不 值得 记 
录 在 序列 化 形式 中 。 因 为 这 样 的 序列 化 形式 过 于 庞大 ， 所 以 ， 把 它 写 到 磁盘 中 ， 或 者 在 
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网 络 上 发 送 都 将 非常 慢 。 


。 它 会 消耗 过 多 的 时 间 。 序 列 化 逻辑 并 不 了 解 对 象 图 的 拓扑 关系 ， 所 以 它 必 须要 经 过 一 
个 昂贵 的 图 遍历 (traversal) 过 程 。 在 上 面 的 例子 中 ， 沿 着 next 引 用 进行 遍历 是 非常 简 
单 的 。 


。 它 会 引起 栈 溢出 。 默 认 的 序列 化 过 程 要 对 对 象 图 执行 一 次 递归 遍历 ， 即 使 对 于 中 等 规 
模 的 对 象 图 ， 这 样 的 操作 也 可 能 会 引起 栈 溢出 。 在 我 的 机 器 上 ， 如 果 StringList 实 例 包 
含 1258 个 元 素 ， 对 它 进行 序列 化 就 会 导致 栈 溢 出 。 到 底 多 少 个 元 素 会 引发 栈 溢 出 ， 这 
要 取决 于 JVM 的 具体 实现 以 及 Java 启 动 时 的 命令 行 参数 ，( 比 如 Heap Size 的 -Xms 与 
-Xmx 的 值 ) 有 些 实现 可 能 根本 不 存在 这 样 的 问题 。 


对 于 StringList 类 ， 合 理 的 序列 化 形式 可 以 非常 简单 ， 只 需 先 包含 链表 中 字符 串 的 数目 ， 
然后 紧 跟着 这 些 字符 串 即 可 。 这 样 就 构成 了 StringList 所 表示 的 逻辑 数据 ， 与 它 的 物理 表示 细 
节 脱 离 。 下 面 是 StringList 的 一 个 修订 版 本 ， 它 包含 writeObject 和 readObject 方 法 ， 用 来 实现 
这 样 的 序列 化 形式 。 顺 便 提 醒 一 下 ，transient 修 饰 符 表 明 这 个 实例 域 将 从 一 个 类 的 默认 序列 化 
形式 中 省 略 掉 : 


// StringList with a reasonable custom serialized form 
public final class StringList implements Serializable { 
private transient int size = Q; 
private transient Entry head = null; 


// No longer Serializable! 
private static class Entry { 
String data; 
Entry next; 
Entry previous; 


// Appends the specified string to the list 
public final void add(String s) { ... } 


[ee . 

* Serialize this {@code StringList} instance. 

* 

* @serialData The size of the list (the number of strings 
* it contains) is emitted ({@code int}), followed by all of 
* its elements (each a {@code String}), in the proper 

* sequence. 


we 
private void writeObject(ObjectOutputStream s) 
throws IOException { 
s.defaultWriteObjectQ); 
s.writeInt(size); 


// Write out all elements in the proper order. 
for (Entry e = head; e != null; e = e.next) 
s.writeObject(e.data); 
} 


private void readObject(ObjectInputStream s) 
throws IOException, ClassNotFoundException { 
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s.defaultReadObject(); 
int numElements = s.readInt(); 


// Read in all elements and insert them in list 5 


for Cint i = 0; i < numElements; i++) 
add((String) s.readObject()); 


.. // Remainder omitted 
} 


注意 ， 尽 管 StringList 的 所 有 域 都 是 瞬时 的 (transient) ， 但 writeObject 方 法 的 首要 任务 仍 
是 调用 defaultWriteObject，readObject 方 法 的 首要 任务 则 是 调用 defaultReadObject。 如 果 所 有 
的 实例 域 都 是 朋 时 的 ; 从 技术 角度 而 言 ， 不 调用 defaultWriteObject 和 defaultReadObject 也 
是 允许 的 ， 但 是 不 推荐 这 样 做 。 即 使 所 有 的 实例 域 都 是 transient 的 ， 调 用 defaultWriteObject 也 
会 影响 该 类 的 序列 化 形式 ， 从 而 极 大 地 增强 灵活 性 。 这 样 得 到 的 序列 化 形式 允许 在 以 后 的 发 
行 版 本 中 增加 非 transient 的 实例 域 ， 并 且 还 能 保持 向 前 或 者 向 后 兼容 性 。 如 果 某 一 个 实例 将 在 
未 来 的 版 本 中 被 序列 化 ， 然 后 在 前 一 个 版 本 中 被 反 序列 化 ， 那 么 ， 后 增加 的 域 将 被 忽略 掉 。 
如 果 旧 版 本 的 readObject 方 法 没有 调用 defaultReadObject， 反 序列 化 过 程 将 失败 ， 引 发 
StreamCorrupted Exception 异 常 。 


注意 ， 尽 管 writeObject 方 法 是 私有 的 ， 它 也 有 文档 注释 。 这 与 Name 类 中 私有 域 的 文档 注 
释 是 同样 的 道理 。 该 私有 方法 定义 了 一 个 公有 的 API， 即 序列 化 形式 ， 并 且 这 个 公有 的 API 应 
该 建立 文档 。 如 同 域 的 @serial 标 签 一 样 ， 方 法 的 @serialData 标 签 也 告知 Javadoc 工 具 ， 要 把 
该 文档 信息 放 在 有 关 序 列 化 形式 的 文档 页 上 。 


套用 以 前 对 性 能 的 讨论 形式 ， 如 果 平 均 字 符 串 长 度 为 10 个 字符 ，StringList 修 订 版 本 的 序 
列 化 形式 就 只 占用 原 序列 化 形式 一 半 的 空间 。 在 我 的 机 器 上 ， 同 样 是 10 个 字符 长 度 的 情况 下 ， 
StringList 修 订 版 的 序列 化 速度 比 原版 本 的 快 2 倍 。 最 终 , 修订 版 中 不 存在 栈 溢出 的 问题 , 因此， 
对 于 可 被 序列 化 的 StringList 的 大 小 也 没有 实际 的 上 限 。 


”虽然 默认 的 序列 化 形式 对 于 StringList 类 来 说 只 是 不 适合 而 已 ， 对 于 有 些 类 ， 情 况 却 变 得 
更 加 精 料 。 对 于 StringList， 上 默认 的 序列 化 形式 不 够 灵活 ， 并 且 执 行 效果 不 佳 ， 但 是 序列 化 和 
反 序列 化 StringList 实 例会 产生 对 原始 对 象 的 忠实 拷贝 ， 它 的 约束 关系 没有 被 破坏 ， 从 这 个 意 
义 上 讲 ， 这 个 序列 化 形式 是 正确 的 。 但 是 ， 如 果 对 象 的 约束 关系 要 依赖 于 特定 于 实现 的 细节 ， 
对 于 它们 来 说 ， 情 况 就 不 是 这 样 了 。 


例如 ， 考 虑 散 列表 的 情形 。 它 的 物理 表示 法 是 一 系列 包含 “ 键 一 值 (key-value)” 项 的 散 、 
列 桶 。 到 底 一 个 项 将 被 放 在 哪个 桶 中 ， 这 是 该 键 的 散 列 码 的 一 个 函数 ， 一 般 情况 下 ， 不 同 的 
JVM 实 现 不 保证 会 有 同样 的 结果 。 实 际 上 ， 即 使 在 同一 个 JVYM 实 现 中 ， 也 无 法 保证 每 次 运行 
都 会 一 样 。 因 此 ， 对 于 散 列表 而 言 ， 接 受 默 认 的 序列 化 形式 将 会 构成 一 个 严重 的 Bug。 对 散 列 
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表 对 象 进行 序列 化 和 反 序 列 化 操作 所 产生 的 对 象 ， 其 约束 关系 会 遭 到 严重 的 破坏 。 


无 论 你 是 否 使 用 默认 的 序列 化 形式 ， 当 defaultWriteObject 方 法 被 调用 的 时 候 ， 每 一 个 未 被 
标记 为 transient 的 实例 域 都 会 被 序列 化 。 因 此 ， 每 一 个 可 以 被 标记 为 transient 的 实例 域 都 应 该 做 
上 这 样 的 标记 。 这 包括 那些 元 余 的 域 ， 即 它们 的 值 可 以 根据 其 他 “基本 数据 域 ” 计 算 而 得 到 的 
域 ， 比 如 缓存 起 来 的 散 列 值 。 它 也 包括 那些 “其 值 依 赖 于 JVM 的 某 一 次 运行 ”的 域 ， 比 如 一 个 
long 域 代表 了 一 个 指向 本 地 数据 结构 的 指针 。 在 决定 将 一 个 域 做 成 非 transient 的 之 前 ， 请 一 定 
要 确信 它 的 值 将 是 该 对 象 逻辑 状态 的 一 部 分 。 如 果 你 正在 使 用 一 种 自 定义 的 序列 化 形式 ， 大 多 
数 实例 域 ， 或 者 所 有 的 实例 域 则 都 应 该 被 标记 为 transient， 就 像 上 面 例子 中 的 StringList 那 样 。 


如 果 你 正在 使 用 默认 的 序列 化 形式 ， 并 且 把 一 个 或 者 多 个 域 标记 为 transient， 则 要 记 住 ， 
当 一 个 实例 被 反 序列 化 的 时 候 ， 这 些 域 将 被 初始 化 为 它们 的 默认 值 (default value); 对 于 对 
象 引 用 域 ， 默 认 值 为 null， 对 于 数值 基本 域 ， 默 认 值 为 0， 对 于 boolean 域 ， 默 认 值 为 false[JLS， 
4.12.5]。 如 果 这 些 值 不 能 被 任何 transient 域 所 接受 ， 你 就 必须 提供 一 个 readObject 方 法 ， 它 首 
先 调 用 defaultReadObject， 然 后 把 这 些 transient 域 恢复 为 可 接受 的 值 ( 见 第 76 条 ) 。 另 一 种 方 
法 是 ， 这 些 域 可 以 被 延迟 到 第 一 次 被 使 用 的 时 候 才 真正 被 初始 化 ( 见 第 71 条 )。 


无 论 你 是 否 使 用 默认 的 序列 化 形式 ， 如 果 在 读 取 整个 对 象 状态 的 任何 其 他 方法 上 强制 任何 
同步 ， 则 也 必须 在 对 象 序列 化 上 强制 这 种 同步 。 因 此 ， 如 果 你 有 一 个 线程 安全 的 对 象 ( 见 第 
70 条 ) ， 它 通过 同步 每 个 方法 实现 了 它 的 线程 安全 ， 并 且 你 选择 使 用 默认 的 序列 化 形式 ， 就 要 
使 用 下 列 的 writeObject 方 法 : 

// write0bject for synchronized class with default serialized form 

private synchronized void writeObject(ObjectOutputStream s) 

throws IOException { 


s.defaultWriteObject(); 
} 


如 果 你 把 同步 放 在 writeObject 方 法 中 ， 就 必须 确保 它 遵 守 与 其 他 动作 相同 的 锁 排 列 
(lock-ordering) 约束 条 件 ， 否 则 就 有 遭遇 资源 排列 (resource-ordering) 死 锁 的 危险 [Goetz06， 
TOT 


不 管 你 选择 了 哪 种 序列 化 形式 ， 都 要 为 自己 编写 的 每 个 可 序列 化 的 类 声明 一 个 显 式 的 序列 
版 本 UID (serial version UID) 。 这 样 可 以 避免 序列 版 本 UID 成 为 潜在 的 不 兼容 根源 ( 见 第 74 
条 )。 而 且 ， 这 样 做 也 会 带 来 小 小 的 性 能 好 处 。 如 果 没 有 提供 显 式 的 序列 版 本 UID ， 就 需要 在 
运行 时 通过 一 个 高 开销 的 计算 过 程 产生 一 个 序列 版 本 UID。 


要 声明 一 个 序列 版 本 UID 非 常 简单 ， 只 要 在 你 的 类 中 增加 下 面 一 行 : 


private static final long serialVersionUID = randomLongValue ; 
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在 编写 新 的 类 时 ， 为 randomLongValue 选 择 什么 值 并 不 重要 。 通 过 在 该 类 上 运行 serialver 
工具 ， 你 就 可 以 得 到 一 个 这 样 的 值 ， 但 是 ， 如 果 你 凭空 编造 一 个 数值 ， 那 也 是 可 以 的 如 果 
你 想 修改 一 个 没有 序列 版 本 UID 的 现 有 的 类 ， 并 希望 新 的 版 本 能 够 接受 现 有 的 序列 化 实例 ， 就 
必须 使 用 那个 自动 为 旧版 本 生成 的 值 。 如 通过 在 旧版 的 类 上 运行 serialver 工 具 @ ， 可 以 得 到 这 
个 数值 一 -被 序列 化 的 实例 为 之 存在 的 那个 数值 。 


如 果 你 想 为 一 个 类 生成 一 个 新 的 版 本 ， 这 个 类 与 现 有 的 类 不 亲 容 (incompatible) ， 那 么 
你 只 需 修改 序列 版 本 UID 声 明 中 的 值 即 可 。 结 果 ， 前 一 版 本 的 实例 经 序列 化 之 后 ， 再 做 反 序 列 
化 时 会 引 发 InvalidClassException 异 常 而 失败 


总 而 言 之 ， 当 你 决定 要 将 一 个 类 做 成 可 序列 化 的 时 候 ( 见 第 74 条 )， 请 仔细 考虑 应 该 采用 
什么 样 的 序列 化 形式 。 只 有 当 默 认 的 序列 化 形式 能 够 合理 地 描述 对 象 的 逻辑 状态 时 ， 才 能 使 
用 默认 的 序列 化 形式 ， 否 则 就 要 设计 一 个 自 定义 的 序列 化 形式 ， 通过 它 合 理 地 描述 对 象 的 状 
态 。 你 应 该 分 配 足 够 多 的 时 间 来 设计 类 的 序列 化 形式 ， 就 好 像 分 配 足够 多 的 时 间 来 设计 它 的 
导出 方法 一 样 ( 见 第 40 条 ) 。 正如 你 无 法 在 将 来 的 版 本 中 去 掉 导 出 方法 一 样 ， 你 也 不 能 去 掉 序 
列 化 形式 中 的 域 ， 它 们 必须 被 永久 地 保留 下 去 ， 以 确保 序列 化 兼容 性 (serialization 
compalibility ) 。 选择 错误 的 序列 化 形式 对 于 一 个 类 的 复杂 性 和 性 能 都 会 有 永久 的 负面 影响 。 


© © serialver 用 法 : serialver [-classpath 类 路 径 ][-show][ 类 名 称 …]。 一 一 译 者 注 





第 39 条 介绍 了 一 个 不 可 变 的 日 期 范围 类 ， 它 包含 可 变 的 私有 Date 域 。 该 类 通过 在 其 构造 
器 和 访问 方法 (accessor) 中 保护 性 地 拷贝 Date 对 象 ， 极 力 地 维护 其 约束 条 件 和 不 可 变性 。 下 
面 就 是 这 个 类 : 


// Immutable class that uses defensive copying 
public final class Period { 

private final Date start; 

private final Date end; 


/wn 
* @param start the beginning of the period 
+ @param end the end of the period; must not precede start 
* @throws IllegalArgumentException if start is after end 
* @throws NullPointerException if start or end is null 
*/ 
public Period(Date start, Date end) { 
this.start = new Date(start.getTime()); 
this.end = new Date(end.getTime()); 
if (this.start.compareTo(this.end) > 0) 
throw new I1legalArgumentException( 
start + " after ”+ end); 
} 
public Date start () { return new Date(start.getTime()); } 
public Date end () { return new Date(end.getTime()); } 
public String toString() { return start + "| - " + end; } 


` ... // Remainder omitted . 


假设 你 决定 要 把 这 个 类 做 成 可 序列 化 的 。 因 为 Period 对 象 的 物理 表示 法 正好 反映 了 它 的 逻 
辑 数据 内 容 ， 所 以 ， 使 用 默认 的 序列 化 形式 并 没有 什么 不 合理 的 〈 见 第 75 条 )。 因 此 ， 为 了 使 
这 个 类 成 为 可 序列 化 的 ， 似 乎 你 所 需要 做 的 也 就 是 在 类 的 声明 中 增加 “implements 
Serializable” 字 样 。 然 而 ， 如 果 你 真 的 这 样 做 ， 那 么 这 个 类 将 不 再 保证 它 的 关键 约束 了 。 


问题 在 于 ，readObject 方 法 实际 上 相当 于 另 一 个 公有 的 构造 器 ， 如 同 其 他 的 构造 器 一 样 ， 
它 也 要 求 注意 同样 的 所 有 注意 事项 。 构 造 器 必须 检查 其 参数 的 有 效 性 ( 见 第 38 条 )， 并 且 在 必 
要 的 时 候 对 参数 进行 保护 性 拷贝 ( 见 第 39 条 )， 同 样 地 ，readObject 方 法 也 需要 这 样 做 。 如 果 
readObject 方 法 无 法 做 到 这 两 者 之 一 ， 对 于 攻击 者 来 说 ， 要 违反 这 个 类 的 约束 条 件 相 对 就 比较 
简单 了 。 


不 严格 地 说 ，readObject 是 一 个 “用 字 节 流 作为 唯一 参数 ”的 构造 器 。 在 正常 使 用 的 情况 
下 ， 对 一 个 正常 构造 的 实例 进行 序列 化 可 以 产生 字 节 流 。 但 是 ， 当 面 对 一 个 人 工 仿造 的 字 节 
流 时 ，readObject 产 生 的 对 象 会 违反 它 所 属 的 类 的 约束 条 件 ， 这 时 问题 就 产生 了 。 假 设 我 们 仅 
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仅 在 Period 类 的 声明 中 加 上 了 “implements Serializable” 字 样 。 那 么 ， 这 个 不 完整 的 程序 将 
产生 一 个 Period 实 例 ， 它 的 结束 时 间 比 起 始 时 间 还 要 早 : 


public class BogusPeriod { 

// Byte stream could not have come from real Period instance! 

private static final byte[] serializedForm = new byte[] { 
(byte)@xac, (byte)@xed, 0x00, 0x05, 0x73, 0x72, 0x00, 0x06, 
0x50, 0x65, 0x72, 0x69, Ox6f, 0x64, 0x40, Ox7e, (byte)ðxf8, 
0x2b, Ox4f, 0x46, (byte)OxcO, (byte)ðxf4, 0x02, 0x00, 0x02, 
Qx4c, 0x00, 0x03, 0x65, Ox6e, 0x64, 0x74, 0x00, 0x10, ðx4c, 
Ox6a, 0x61, 0x76, 0x61, Ox2f, 0x75, 0x74, 0x69, Ox6c, Ox2f, 
0x44, 0x61, 0x74, 0x65, Ox3b, Ox4c, 0x00, 0x05, 0x73, 0x74, 
0x61, 0x72, 0x74, 0x71, 0x00, @x7e, 0x00, Ox@1, 0x78, 0x70, 
0x73, 0x72, 0x00, 0xðe, Ox6a, Ox61, 0x76, 0x61, ðx2e, 0x75, 
0x74, 0x69, Ox6c, 0x2e, 0x44, Ox61, 0x74, 0x65, 0x68, 0x6a, 
(byte)ðx81, @x@1, 0x4b, 0x59, 0x74, 0x19, 0x03, 0x00, 0x00, 
0x78, 0x70, 0x77, 0x08, 0x00, 0x00, 0x00, 0x66, (byte)ðxdf, 
Qx6e, Oxle, 0x00, 0x78, 0x73, 0x71, 0x00, Ox7e, 0x00, 0x03, 
0x77, 0x08, 0x00, 0x00, 0x00, (byte)ðxd5, 0x17, 0x69, 0x22, 
0x00, 0x78 }; 


public static void main(String[] args) { 
Period p = (Period) deserialize(serializedForm); 
System.out.printin(p); 
} 
// Returns the object with the specified serialized form 
private static Object deserialize(byte[] sf) { 
try { 
InputStream is = new ByteArrayInputStream(sf) ; 
ObjectInputStream ois = new ObjectInputStream(is); 
return ois.readObject(); 
} catch (Exception e) { 
throw new I1legalArgumentException(e) ; 
} 


} 


被 用 来 初始 化 serializedForm 的 byte 数 组 常量 是 这 样 产生 的 : 首先 对 一 个 正常 的 Period 实 例 
进行 序列 化 ， 然 后 对 得 到 的 字 节 流 进行 手工 编辑 。 对 于 这 个 例子 而 言 ， 字 节 流 的 细节 并 不 重 
要 ， 但 是 如 果 你 很 好 奇 的 话 ， 可 以 在 《Javar Object Serialization Specification》 
[Serialization, 6] 中 查 到 有 关 序 列 化 字 节 流 格式 的 描述 信息 。 如 果 你 运行 这 个 程序 ， 它 会 打印 
iH “Fri Jan 01 12:00:00 PST 1999 - Sun Jan 01 12:00:00 PST 1984”。 只 要 把 Period 声 明成 可 
序列 化 的 ， 就 会 使 我 们 创建 出 违反 其 类 约束 条 件 的 对 象 。 


为 了 修正 这 个 问题 ， 你 可 以 为 Period 提 供 一 个 readObject 方 法 ， 该 方法 首先 调用 
defaultReadObject， 然 后 检查 被 反 序列 化 之 后 的 对 象 的 有 效 性 。 如 果 有 效 性 检查 失败 ， 
readObject 方 法 就 抛 出 一 个 InvalidObjectException 异 常 ， 使 反 序列 化 过 程 不 能 成 功 地 完成 : 


// readObject method with validity checking 
private void readObject(ObjectInputStream s) 
throws IOException, ClassNotFoundException { 
s.defaultReadObject(); 


// Check that our invariants are satisfied 
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if (start.compareTo(end) > @) 
throw new InvalidObjectException(start +" after "+ end); 


} 


尽管 这 样 的 修正 避免 了 攻击 者 创建 无 效 的 Period 实 例 ， 但 是 ， 这 里 仍然 隐藏 着 一 个 更 为 微 
妙 的 问题 。 通 过 伪造 字 节 流 ， 要 想 创建 可 变 的 Period 实 例 仍 是 有 可 能 的 ， 做 法 是 : 字 节 流 以 一 
个 有 效 的 Period 实 例 开头 ， 然 后 附加 上 两 个 额外 的 引用 ， 指 向 Period 实 例 中 的 两 个 私有 的 Date 
域 。 攻 击 者 从 ObjectInputStream 中 读 取 Period 实 例 ， 然 后 读 取 附加 在 其 后 面 的 “恶意 编制 的 对 
象 引 用 ”。 这 些 对 象 引 用 使 得 攻击 者 能 够 访问 到 Period 对 象 内 部 的 私有 Date 域 所 引用 的 对 象 。 
通过 改变 这 些 Date 实 例 ， 攻 击 者 可 以 改变 Period 实 例 。 下 面 的 类 演示 了 这 种 攻击 : 


public class MutablePeriod { 
// A period instance 
public final Period period; 


// period's start field, to which we shouldn't have access 
public final Date start; 


// periods end field, to which we shouldn't have access 
public final Date end; 
public MutablePeriod() { 

try { 


ByteArrayOutputStream bos = 

new ByteArrayOutputStream() ; 
ObjectOutputStream out = 

new ObjectOutputStream(bos) ; 


// Serialize a valid Period instance 
out.writeObject(new Period(new Date(), new Date())); 


/* 
* Append rogue “previous object refs" for internal 
* Date fields in Period. For details, see "Java 
+ Object Serialization Specification," Section 6.4. 


*/ 
byte[] ref = { 0x71, 0, Ox7e, ©, 5 }; // Ref #5 
bos.write(ref); // The start field 
ref[4] = 4; // Ref #4 
bos.write(ref); // The end field 


// Deserialize Period and "stolen" Date references 
ObjectInputStream in = new ObjectInputStream( 

new ByteArrayInputStream(bos.toByteArray())); 
period = (Period) in.readObject(); 

start = (Date) in.readObject(); 

end = (Date) in.readObject(); 


} catch (Exception e) { 


} 


throw new AssertionError(e); 


运行 下 面 的 程序 ， 可 以 看 到 攻击 的 效果 : 


public static void main(String[] args) { 
MutablePeriod mp = new MutablePeriod(); 
Period p = mp.period; 
Date pEnd = mp.end; 


i 


// Let's turn back the clock 
pEnd.setYear (78); 
System.out.printIn(p); 
// Bring back the 60s! 
pEnd. setYear (69) ; 
System.out.printin(p); 

} 


运行 这 个 程序 ， 产 生 如 下 的 输出 结果 : 


Wed Apr @2 11:04:26 PDT 2008 - Sun Apr 02 11:04:26 PST 1978 
Wed Apr @2 11:04:26 PDT 2008 - Wed Apr @2 11:04:26 PST 1969 


虽然 Period 实 例 被 创建 之 后 ， 它 的 约束 条 件 没 有 被 破坏 ， 但 是 要 随意 地 修改 它 的 内 部 组 件 
仍然 是 有 可 能 的 。 一 旦 攻击 者 获得 了 一 个 可 变 的 Period 实 例 ， 他 就 可 以 将 这 个 实例 传递 给 一 个 
“安全 性 依赖 于 Period 的 不 可 变性 ”的 类 ， 从 而 造成 更 大 的 危害 。 这 种 推断 并 不 牵强 : 实际 上 ， 
有 许多 类 的 安全 性 就 是 依赖 于 String 的 不 可 变性 。 


问题 的 根源 在 于 ，Period 的 readObject 方 法 并 没有 完成 足够 的 保护 性 拷贝 。 当 一 个 对 象 补 
反 序 列 化 的 时 候 ， 对 于 客户 痛 不 应 该 拥有 的 对 象 引 用 ， 如 果 哪 个 域 包含 了 这 样 的 对 象 引 用 ， 
就 必须 要 做 保护 性 找 贝 ， 这 是 非常 重要 的 。 因 此 ， 对 于 每 个 可 序列 化 的 不 可 变 类 ， 如 果 它 包 
含 了 私有 的 可 变 组 件 ， 那 么 在 它 的 readObject 方 法 中 ， 必 须要 对 这 些 组 件 进行 保护 性 拷贝 。 下 
面 的 readObject 方 法 可 以 确保 Period 的 约束 条 件 不 会 遭 到 破坏 ， 以 保持 它 的 不 可 变性 : 
// readObject method with defensive copying and validity checking 
private void readObject(ObjectInputStream s) 
throws IOException, ClassNotFoundException { 
s.defaultReadObject(); 
// Defensively copy our mutable components 
start = new Date(start.getTime()); 
end = new Date(end.getTime()); 
// Check that our invariants are satisfied 
if (start.compareTo(end) > 0) 


throw new InvalidObjectException(start +" after "+ end); 
} . 


注意 ， 保 护 性 拷贝 是 在 有 效 性 检查 之 前 进行 的 ， 而 且 ， 我 们 没有 使 用 Date 的 clone 方 法 来 
执行 保护 性 拷贝 。 这 两 个 细节 对 于 保护 Period 免 受 攻 击 是 必要 的 ( 见 第 39 条 )。 同 时 也 要 注意 
到 ， 对 于 final 域 ， 保 护 性 拷贝 是 不 可 能 的 。 为 了 使 用 readObject 方 法 ， 我 们 必须 要 将 start 和 
end 域 做 成 非 final 的 。 这 是 很 遗憾 的 ， 但 是 这 还 算是 相对 比较 好 的 做 法 。 有 了 这 个 新 的 


readObject 方 法 ， 并 去 掉 了 start 和 end 域 的 final 修 饰 符 之 后 ，MnutablePeriod 类 将 不 再 有 效 。 此 


时 ， 上 面 的 攻击 程序 会 产生 这 样 的 输出 : 


Wed Apr @2 11:05:47 PDT 2008 - Wed Apr @2 11:05:47 PDT 2008 
Wed Apr @2 11:05:47 PDT 2008 - Wed Apr @2 11:05:47 PDT 2008 
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在 Java 1.4 发 行 版 本 中 ， 为 了 阻止 恶意 的 对 象 引用 攻击 ， 同 时 节省 保护 性 拷贝 的 开销 ， 在 
ObjectOutputStream 中 增加 了 writeUnshared 和 readUnshared 方 法 [Serialization]。 遗 憾 的 是 ， 
这 些 方法 都 很 容易 受到 复杂 的 攻击 ， 即 本 质 上 与 第 77 条 中 所 述 的 ElvisStealer 攻 击 相似 的 攻击 。 
不 要 使 用 writeUnshared 和 readUnshared 方 法 。 它 们 通常 比 保护 性 拷贝 更 快 ， 但 是 它们 不 提 
供 必 要 的 安全 性 保护 。 


有 一 个 简单 的 “ 石 蕊 ”测试 ， 可 以 用 来 确定 默认 的 readObject 方 法 是 否 可 以 被 接受 。 测 试 
方法 : 增加 一 个 公有 的 构造 器 ， 其 参数 对 应 于 该 对 象 中 每 个 非 transient 的 域 ， 并且 无 论 参 数 的 
值 是 什么 ， 都 是 不 进行 检查 就 可 以 保存 到 相应 的 域 中 的 。 对 于 这 样 的 做 法 ， 你 是 否 会 感到 很 
舒适 ? 如 果 你 对 这 个 问题 的 回答 是 否定 的 ， 就 必须 提供 一 个 显 式 的 readObject 方 法 ， 并 且 它 必 
须 执行 构造 器 所 要 求 的 所 有 有 效 性 检查 和 保护 性 拷贝 。 另 一 种 方法 是 ， 可 以 使 用 序列 化 代理 
模式 (serialization proxy pattern) ， 见 第 78 条 。 


对 于 非 final 的 可 序列 化 的 类 ， 在 readObject 方 法 和 构造 器 之 间 还 有 其 他 类 似 的 地 方 。 
readObject 方 法 不 可 以 调用 可 被 覆盖 的 方法 ， 无 论 是 直接 调用 还 是 间接 调用 都 不 可 以 ( 见 第 17 
条 )。 如 果 违 反 了 这 条 规则 ， 并 且 和 覆盖 了 该 方法 ， 被 覆盖 的 方法 将 在 子 类 的 状态 被 反 序列 化 之 
前 先 运行 。 程 序 很 可 能 会 失败 [Bloch05，Puzzle91]。 


总 而 言 之 ， 每 当 你 编写 readObject 方 法 的 时 候 ， 都 要 这 样 想 : 你 正在 编写 一 个 公有 的 构造 
器 ， 无 论 给 它 传递 什么 样 的 字 节 流 ， 它 都 必须 产生 一 个 有 效 的 实例 。 不 要 假设 这 个 字 节 流 一 
定 代 表 着 一 个 真正 被 序列 化 过 的 实例 。 虽 然 在 本 条 目的 例子 中 ， 类 使 用 了 默认 的 序列 化 形式 ， 
但 是 ， 所 有 讨论 到 的 有 可 能 发 生 的 问题 也 同样 适用 于 使 用 自 定义 序列 化 形式 的 类 。 下 面 以 摘 
要 的 形式 给 出 一 些 指导 方针 ， 有 助 于 编写 出 更 加 健壮 的 readObject 方 法 : 


© 对 于 对 象 引 用 域 必须 保持 为 私有 的 类 ， 要 保护 性 地 拷贝 这 些 域 中 的 每 个 对 象 。 不 可 变 类 
的 可 变 组 件 就 属于 这 一 类 别 。 ; 


* 对 于 任何 约束 条 件 ， 如 果 检 查 失败 ， 则 抛 出 一 个 InvalidObjectException 异 常 。 这 些 检查 
动作 应 该 跟 在 所 有 的 保护 性 拷贝 之 后 。 


© 如果 整 个 对 象 图 在 被 反 序列 化 之 后 必须 进行 验证 ， 就 应 该 使 用 ObjectInputValidation 接 
A[JavaSE6, Serialization], 


“无 论 是 直接 方式 还 是 间接 方式 ， 都 不 要 调用 类 中 任何 可 被 覆盖 的 方法 。 





第 3 条 讲述 了 Singleton 模 式 ， 并 且 给 出 了 以 下 这 个 Singleton 类 的 示例 。 这 个 类 限制 了 对 其 
构造 器 的 访问 ， 以 确保 永远 只 创建 一 个 实例 : 


public class Elvis { 
public static final Elvis INSTANCE = new Elvis(); 
private Elvis() { ... } 


public void leaveTheBuilding() { ... } 


正如 在 第 3 条 中 提 到 的 ， 如 果 这 个 类 的 声明 中 加 上 了 “implements Serializable” 的 字样 ， 
它 就 不 再 是 一 个 Singleton。 无 论 该 类 使 用 了 默认 的 序列 化 形式 ， 还 是 自 定义 的 序列 化 形式 
( 见 第 75 条 )， 都 没有 关系 ， 也 跟 它 是 否 提供 了 显 式 的 readObject 方 法 ( 见 第 76 条 ) 无 关 。 任 何 
一 个 rehdObject 方 法 ， 不 管 是 显 式 的 还 是 默认 的 ， 它 都 会 返回 一 个 新 建 的 实例 ， 这 个 新 建 的 实 
例 不 同 于 该 类 初始 化 时 创建 的 实例 。 


readResolve 特 性 允许 你 用 readObject 创 建 的 实例 代替 另 一 个 实例 [Serialization, 3.7]。 对 于 
一 个 正在 被 反 序列 化 的 对 象 ， 如 果 它 的 类 定义 了 一 个 readResolve 方 法 ， 并 且 具 备 正确 的 声明 ， 
那么 在 反 序列 化 之 后 ， 新 建 对 象 上 的 readResolve 方 法 就 会 被 调用 。 然 后 ， 该 方法 返回 的 对 象 
引用 将 被 返回 ， 取 代 新 建 的 对 象 。 在 这 个 特性 的 绝 大 多 数 用 法 中 ， 指 向 新 建 对 象 的 引用 不 需 
要 再 被 保留 ， 因 此 立即 成 为 垃圾 回收 的 对 象 。 


如 果 Elvis 类 要 实现 Serializable 接 口 ， 下 面 的 readResolve 方 法 就 足以 保证 它 的 Singleton 
属性 : 

// readResolve for. instance control - you can do better! 

private Object readResolve() { 

// Return the one true Elvis and let the garbage collector 
// take care of the Elvis impersonator. - 

; return INSTANCE; 

该 方法 忽略 了 被 反 序 列 化 的 对 象 ， 只 返回 该 类 初始 化 时 创建 的 那个 特殊 的 Elvis 实 例 。 因 
此 ，Elvis 实 例 的 序列 化 形式 并 不 需要 包含 任何 实际 的 数据 ， 所 有 的 实例 域 都 应 该 被 声明 为 
transient 的 。 事 实 上 ， 如 果 依 赖 readResolve 进 行 实例 控制 ， 带 有 对 象 引 用 类 型 的 所 有 实例 域 
则 都 必须 声明 为 transient 的 。 否 则 ， 那 种 破 签 沉 舟 式 的 攻击 者 ， 就 有 可 能 在 readResolve 方 法 
被 运行 之 前 ， 保 护 指向 反 序 列 化 对 象 的 引用 ， 采 用 的 方法 类 似 于 在 第 76 条 中 提 到 过 的 
MutablePeriod 攻 击 。 


这 种 攻击 有 点 复杂 ， 但 是 背后 的 思想 却 很 简单 。 如 果 Singleton 包 含 一 个 非 transient 的 对 象 
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引用 域 ， 这 个 域 的 内 容 就 可 以 在 Singleton 的 readResolve 方 法 运行 之 前 被 反 序 列 化 。 当 对 象 引 
用 域 的 内 容 被 反 序 列 化 时 ， 它 就 允许 一 个 精心 制作 的 流 “ 次 用 ”指向 最 初 被 反 序列 化 的 
Singleton 的 引用 。 


以 下 是 它 更 详细 的 工作 原理 。 首 先 ， 编 写 一 个 “盗用 者 ”类 ， 它 既 有 readResolver 方 法 ， 
又 有 实例 域 ， 实 例 域 指向 被 序列 化 的 Singleton 的 引用 ,“ 盗 用 者 ”类 就 “潜伏 ”在 其 中 。 在 序 
列 化 流 中 ， 用 “盗用 者 ”类 的 实例 代 赫 Singleton 的 非 transient 时 域 。 你 现在 就 有 了 一 个 循环 : 
Singleton 包 含 “ 次 用 者 ”类 ,“ 次 用 者 ”类 则 引用 该 Singleton，。 


由 于 Singleton 包 含 “ 盗 用 者 ”类 ， 当 这 个 Singleton 被 反 序列 化 时 , “盗用 者 ”类 的 
readResolve 方 法 先 运行 。 因 此 ， 当 “盗用 者 ”的 readResolve 方 法 运行 时 ， 它 的 实例 域 仍然 引 
用 被 部 分 反 序列 化 (并且 也 还 没有 被 解析 ) 的 Singleton。 


“盗用 者 ”的 readResolve 方 法 从 它 的 实例 域 中 将 引用 复制 到 静态 域 中 ， 以 便 该 引用 可 以 在 
readResolve 方 法 运行 之 后 被 访问 到 。 然 后 这 个 方法 为 它 所 藏身 的 那个 域 返回 一 个 正确 的 类 型 
值 。 如 果 没 有 这 么 做 ， 当 序列 化 系统 试 着 将 “盗用 者 ”引用 保存 到 这 个 域 中 时 ，VM 就 会 抛 出 


ClassCastException, 


为 了 更 具体 地 说 明 这 一 点 ， 我 们 来 考虑 下 面 这 个 有 问题 的 Singleton: 


// Broken singleton - has nontransient object reference field! 
public class Elvis implements Serializable { 

public static final Elvis INSTANCE = new Elvis(); 

private Elvis() { } 


private String[] favoriteSongs = 
{ “Hound Dog", “Heartbreak Hotel" }; 

public void printFavorites() { 
System.out.printIn(Arrays.toString(favoriteSongs)) ; 


private Object readResolve() { 
return INSTANCE; 


} 
下 面 是 个 “盗用 者 ”类 ， 是 根据 上 述 的 描述 构造 的 : 


public class ElvisStealer implements Serializable { 
static Elvis impersonator; 
private Elvis payload; 


private Object readResolve() { 
// Save a reference to the "unresolved" Elvis instance 
impersonator = payload; 


// Return an object of correct type for favorites field 
return new String[] { "A Fool Such as I" }; 


private static final long serialVersionUID = ð; 
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CC 
最 后 ， 这 是 一 个 不 完整 的 程序 ， 它 反 序列 化 一 个 手工 制作 的 流 ， 为 那个 有 缺陷 的 Singleton 
产生 两 个 截然 不 同 的 实例 。 这 个 程序 中 省 略 了 反 序 列 化 方法 ， 因 为 它 与 第 267 页 中 的 
一 样 : 


public class ElvisImpersonator { 
// Byte stream could not have come from real Elvis instance! 
private static final byte[] serializedForm = new byte[] { 
(byte)Oxac, (byte)@xed, 0x00, 0x05, 0x73, 0x72, 0x00, 0x05, 
0x45, @x6c, 0x76, 0x69, 0x73, (bytejðx84, (byte)ðxe6, 
(byte)0x93, 0x33, (byte)ðxc3, (byte)ðxf4, (byte)ðx8b, 
0x32, 0x02, 0x00, Ox01, Ox4c, 0x0ð, OxƏd, 0x66, 0x61, 0x76, 
Ox6f, 0x72, 0x69, 0x74, 0x65, 0x53, Ox6f, Ox6e, 0x67, 0x73, 
0x74, 0x00, 0x12, Ox4c, Ox6a, Ox61, 0x76, 0x61, Ox2f, Ox6c, 
0x61, Ox6e, Ox67, Ox2f, Ox4f, Ox62, Ox6a, 0x65, 0x63, 0x74, 
0x3b, 0x78, 0x70, 0x73, 0x72, 0x00, Oxdc, 0x45, Ox6c, 0x76, 
0x69, 0x73, 0x53, 0x74, 0x65, @x61, Ox6c, 0x65, 0x72, 0x00, 
9x00，0x00，0x00，0x00，0x00，0x00， 09x00，0x02，0x00，0x01， 
0x4c，0x00，0x07，0x70，0x61，6x79，0x6c，6x6f， 0x61, 0x64, 
0x74, 0x00, 0x07, Ox4c, 0x45, Ox6c, 0x76, 0x69, 0x73, Ox3b, 
0x78, 0x70, 0x71, 0x00, Ox7e, Ox00, 0x02 
public static void main(String[] args) { 
// Initializes ElvisStealer. impersonator and returns 
// the real Elvis (which is Elvis. INSTANCE) 
Elvis elvis = (Elvis) deserialize(serializedForm); 
Elvis impersonator = ElvisStealer. impersonator; 


elvis.printFavorites(); 
impersonator. printFavorites(); 
} 
} 


运行 这 个 程序 会 产生 下 列 输出 ， 最 终 证 明 可 以 创建 两 个 截然 不 同 的 Elvis 实 例 (包含 两 种 
不 同 的 音乐 品位 ) : 

{Hound Dog, Heartbreak Hotel] 

[A Fool Such as I] 

通过 将 favorites 域 声明 为 transient， 可 以 修正 这 个 问题 ， 但 是 最 好 把 Elvis 做 成 是 一 个 单元 素 
的 枚 举 类 型 (MEIR) 进行 修正 。 从 历史 上 看 ，readResolve 方 法 被 用 于 所 有 可 序列 化 的 实例 受 
控 (instance-Controlled) 的 类 。 自 从 Java 1.5 发 行 版 本 以 来 ， 它 就 不 再 是 在 可 序列 化 的 类 中 维持 
实例 控制 的 最 佳 方法 了 。 就 如 ElvisStealer 攻 击 所 示范 的 ， 这 种 方法 很 脆弱 ， 需 要 万 分 谨慎 。 


如 果 反 过 来 ， 你 将 一 个 可 序列 化 的 实例 受 控 的 类 编写 成 枚 举 ， 就 可 以 绝对 保证 除了 所 声明 
的 常量 之 外 ， 不 会 有 别 的 实例 。JVM 对 此 提供 了 保障 ， 这 一 点 你 可 以 确信 无 疑 。 从 你 这 方面 
来 讲 ， 并 不 需要 特别 注意 什么 。 以 下 是 把 Elvis 写 成 枚 举 的 例子 : 


// Enum singleton - the preferred approach 
public enum Elvis { 
INSTANCE; 
private String[] favoriteSongs = 
{ "Hound Dog", "Heartbreak Hotel" }; 
public void printFavorites() { 
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System. out.printin(Arrays.toString(favoriteSongs)) ; 
5 } 
用 readResolve 进 行 实例 控制 并 不 过 时 。 如 果 必 须 编写 可 序列 化 的 实例 受 控 的 类 ， 它 的 实 
例 在 编译 时 还 不 知道 ， 你 就 无 法 将 类 表示 成 一 个 枚 举 类 型 。 


readResolve 的 可 访问 性 (accessibility) 很 重要 。 如 果 把 readResolve 方 法 放 在 一 个 final 
类 上 ， 它 就 应 该 是 私有 的 。 如 果 把 readResolver 方 法 放 在 一 个 非 final 的 类 上 ;就 必须 认真 考虑 
它 的 可 访问 性 。 如 果 它 是 私有 的 ， 就 不 适用 于 任何 子 类 。 如 果 它 是 包 级 私有 的 ， 就 只 适用 于 
同一 个 包 中 的 子 类 。 如 果 它 是 受 保护 的 或 者 公有 的 ， 就 适用 于 所 有 没有 覆盖 它 的 子 类 。 如 果 
readResolve 方 法 是 受 保护 的 或 者 公有 的 ， 并 且 子 类 没有 覆盖 它 ， 对 序列 化 过 的 子 类 实例 进行 
反 序列 化 ， 就 会 产生 一 个 超 类 实例 ， 这 样 有 可 能 导致 ClassCastException 异 常 。 


总 而 言 之 ， 你 应 该 尽 可 能 地 使 用 枚 举 类 型 来 实施 实例 控制 的 约束 条 件 。 如 果 做 不 到 ， 同 时 又 
需要 一 个 既 可 序列 化 又 是 实例 受 控 (instance-controlled) 的 类 ， 就 必须 提供 一 个 readResolver 方 
法 ， 并 确保 该 类 的 所 有 实例 域 都 为 基本 类 型 ， 或 者 是 transient 的 。 





正如 第 74 条 中 提 到 以 及 本 章 中 所 讨论 的 ， 决 定 实现 Serializable 接 口 ， 会 增加 出 错 和 出 现 
安全 问题 的 可 能 性 ， 因 为 它 导 致 实例 要 利用 语言 之 外 的 机 制 来 创建 ， 而 不 是 用 普通 的 构造 器 。 
然而 ， 有 一 种 方法 可 以 极 大 地 减少 这 些 风险 。 这 种 方法 就 是 序列 化 代理 模式 (serialization 


proxy pattern) 。 


FRAC REE BAAS A, SE, TERR — TA RE, ML 
AAs Db FAY SE AY EAR AS. NR EAE RE PCR IZ (serialization proxy)， 它 应 该 
有 一 个 单独 的 构造 器 ， 其 参数 类 型 就 是 那个 外 围 类 。 这 个 构造 器 只 从 它 的 参数 中 复制 数据 : 
它 不 需要 进行 任何 一 致 性 检查 或 者 保护 性 拷贝 。 从 设计 的 角度 来 看 ， 序 列 化 代理 的 默认 序列 
化 形式 是 外 围 类 最 好 的 序列 化 形式 。 外 围 类 及 其 序列 代理 都 必须 声明 实现 Serializable 接 口 。 


例如 ， 考 虑 第 39 条 中 编写 的 不 可 变 的 Period 类 ， 并 在 第 76 条 中 做 成 可 序列 化 的 。 以 下 是 
这 个 类 的 一 个 序列 化 代理 。Period 是 如 此 简单 ， 以 致 它 的 序列 化 代理 有 着 与 类 完全 相同 
的 域 : 
// Serialization proxy for Period class 
private static class SerializationProxy implements Serializable { 
private final Date start; 
private final Date end; 
SerializationProxy(Period p) { 
this.start = p.start; 
this.end = p.end; 
} 
private static final long serialVersionUID = 
; 234098243823485285L; // Any number will do (Item 75) 
接 下 来 ， 将 下 面 的 writeReplace 方 法 添加 到 外 围 类 中 。 通 过 序列 化 代理 ， 这 个 方法 可 以 被 
逐 字 地 复制 到 任何 类 中 : 
// writeReplace method for the serialization proxy pattern 


private Object writeReplace() { 
return new SerializationProxy(this); 


这 个 方法 的 存在 导致 序列 化 系统 产生 一 个 SerializationProxy 实 例 ， 代 替 外 围 类 的 实例 。 换 
句 话说 ，writeReplace 方 法 在 序列 化 之 前 ， 将 外 围 类 的 实例 转变 成 了 它 的 序列 化 代理 。 


有 了 这 个 writeReplace 方 法 之 后 ， 序 列 化 系统 永远 不 会 产生 外 围 类 的 序列 化 实例 ， 但 是 攻 
击 者 有 可 能 伪造 ， 企 图 违反 该 类 的 约束 和 条件。 为 了 确保 这 种 攻击 无 法 得 偿 ， 只 要 在 外 围 类 中 
添加 这 个 readObject 方 法 即 可 : 
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// readObject method for the serialization proxy pattern 
private void readObject(ObjectInputStream stream) 
throws InvalidObjectException { 
throw new InvalidObjectException("Proxy required"); 


最 后 ， 在 SerializationProxy 类 中 提供 一 个 readResolve 方 法 ， 它 返回 一 个 逻辑 上 相当 的 外 
围 类 的 实例 。 这 个 方法 的 出 现 ， 导 致 序列 化 系统 在 反 序列 化 时 将 序列 化 代理 转变 回 外 围 类 的 
实例 。 


这 个 readResolve 方 法 仅仅 利用 它 的 公有 API 创 建 外 围 类 的 一 个 实例 ， 这 正 是 该 模式 的 魅力 
之 所 在 。 它 极 大 地 消除 了 序列 化 机 制 中 语言 本 身 之 外 的 特征 ， 因 为 反 序 列 化 实例 是 利用 与 任 
何其 他 实例 相同 的 构造 器 、 静 态 工 厂 和 方法 而 创建 的 。 这 样 你 就 不 必 单 独 确 保 被 反 序列 化 的 
实例 一 定 要 遵守 类 的 约束 条 件 。 如 果 该 类 的 静态 工厂 或 者 构造 器 建立 了 这 些 约 束 条 件 ， 并且 
它 的 实例 方法 在 维持 着 这 些 约束 条 件 ， 你 就 可 以 确信 序列 化 也 会 维持 这 些 约束 条 件 。 


以 下 是 上 述 Period.SerializationProxy 的 readResolve 方 法 : 


// readResolve method for Period.Serial izationProxy 
private Object readResolve() { 
return new Period(start, end); // Uses public constructor 


正如 保护 性 拷贝 方法 一 样 〈 见 第 269 页 ) ， 序 列 化 代理 方法 可 以 阻止 伪 字 节 流 的 攻击 ( 见 
第 267 页 ) 以 及 内 部 域 的 盗用 攻击 ( 见 第 268 页 )。 与 前 两 种 方法 不 同 ， 这 种 方法 允许 Period 的 
域 为 final 的 ， 为 了 确保 Period 类 真正 是 不 可 变 的 ( 见 第 15 条 )， 这 一 点 很 有 必要 。 与 前 两 种 方 
法 不 同 的 还 有 ， 这 种 方法 不 需要 太 费 心思 。 你 不 必 知 道 哪些 域 可 能 受到 狭 独 的 序列 化 攻击 的 
威胁 ， 你 也 不 必 显 式 地 执行 有 效 性 检查 ， 作 为 反 序列 化 的 一 部 分 。 


还 有 一 种 方法 ， 利 用 这 种 方法 时 ， 序 列 化 代理 模式 的 功能 比 保护 性 拷贝 的 更 加 强大 。 序 列 
化 代理 模式 允许 反 序 列 化 实例 有 着 与 原始 序列 化 实例 不 同 的 类 。 你 可 能 认为 这 在 实际 应 用 中 
没有 什么 作用 ， 其 实 不 然 。 


考虑 EnumSet 的 情况 ( 见 第 32 条 )。 这 个 类 没有 公有 的 构造 器 ， 只 有 静态 工厂 。 从 客户 的 
角度 来 看 ， 它 们 返回 EnumSet 实 例 ， 但 是 实际 上 ， 它 们 是 返回 两 种 子 类 之 一 ， 具 体 取决 于 底层 
枚 举 类 型 的 大 小 ( 见 第 1 条 ， 第 6 页 )。 如 果 底 层 的 枚 举 类 型 有 64 个 或 者 少 于 64 个 的 元 素 ， 静态 
工厂 就 返回 一 个 RegularEnumSet; 否则 , 它们 就 返回 一 个 JumboEnumSet。 现在 考虑 这 种 情况 : 
如 果 序 列 化 一 个 枚 举 集合 ， 它 的 枚 举 类 型 有 60 个 元 素 ， 然 后 给 这 个 枚 举 类 型 再 增加 5 个 元 素 ， 
之 后 反 序 列 化 这 个 枚 举 集合 。 当 它 被 序列 化 的 时 候 ， 是 一 个 RegularEnumSet 实 例 ， 但 是 一 旦 
它 被 反 序列 化 ， 它 最 好 是 一 个 JumboEnumSet 实 例 。 实 际 发 生 的 情况 正 是 如 此 ， 因 为 EnumSet 
使 用 序列 化 代理 模式 。 如 果 你 有 兴趣 ， 可 以 看 看 EnumSet 的 这 个 序列 化 代理 ， 它 实际 上 就 这 么 
简单 : 


序列 化 arte 
// EnumSet's serialization proxy 
private static class SerializationProxy <E extends Enum<E>> 
implements Serializable { 
// The element type of this enum set. 
private final Class<E> elementType; 


// The elements contained in this enum set. 
private final Enum[] elements; 


SerializationProxy(EnumSet<E> set) { 


elementType = set.elementType; 
elements = set.toArray(EMPTY_ENUM_ARRAY); // (Item 43) 


private Object readResolve() { 
EnumSet<E> result = EnumSet.noneOf(elementType) ; 
for (Enum e : elements) 

result.add((E)e); 

return result; 

} 

private static final long serialVersionUID = 
362491234563181265L; 

} 


序列 化 代理 模式 有 两 个 局 限 性 。 它 不 能 与 可 以 被 客户 端 扩 展 的 类 兼容 ( 见 第 17 条 )。 它 也 
不 能 与 对 象 图 中 包含 循环 的 某 些 类 兼容 :如果 你 企图 从 一 个 对 象 的 序列 化 代理 的 readResolve 
方法 内 部 调用 这 个 对 象 中 的 方法 ， 就 会 得 到 一 个 ClassCastException 异 常 ， 因 为 你 还 没有 这 个 
对 象 ， 只 有 它 的 序列 化 代理 。 


最 后 ， 序 列 化 代理 模式 所 增强 的 功能 和 安全 性 并 不 是 没有 代价 的 。 在 我 的 机 器 上 ， 通 过 序 
列 化 代理 来 序列 化 和 反 序列 化 Period 实 例 的 开销 ， 比 用 保护 性 拷贝 进行 的 开销 增加 了 14%。 


总 而 言 之 ， 每 当 你 发 现 自己 必须 在 一 个 不 能 被 客户 端 扩展 的 类 上 编写 readObject 或 者 
writeObject 方 法 的 时 候 ， 就 应 该 考虑 使 用 序列 化 代理 模式 。 要 想 稳健 地 将 带 有 重要 约束 条 件 
的 对 象 序列 化 时 ， 这 种 模式 可 能 是 最 容易 的 方法 。 
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local class 局 部 类 

marker annotation 标记 注解 
marker interface 标记 接口 
member KA” 

member class 成 员 类 
member interface 成 员 接口 
memory footprint ”内 存 占 用 
memory model 内 存 模 型 
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meta-annotation “元 注解 
method 方法 

migration compatibility “移植 兼容 性 
mixin 混合 类 型 

module 模块 

mutator 设 值 方法 

naming convention 命名 惯例 
naming pattern 命名 模式 

native method 本 地 方法 

native object 本 地 对 象 

nested class {##% 
non-reifiable 不 可 具体 化 的 
nonstatic member class 非 静态 的 成 员 类 
object 对 象 

object pool 对 象 池 

object serialization ”对 象 序列 化 
obsolete reference 过 期 引用 
open call 开放 调用 

operation code 操作 码 
overload 重 载 

override 覆盖 

package-private MRA 
parameterized type 参数 化 的 类 型 
performance model 性 能 模型 
postcondition ”后 置 条 件 
precondition 前 提 条 件 
precondition violation “前 提 违 例 
primitive ”基本 类 型 

private 私有 的 

public 公有 的 

raw type 原生 态 类 型 ; 
recursive type bound 递归 类 型 限制 
redundant field TAR 
reference type 引用 类 型 
reflection 反射 机 制 

register 注册 

reifiable 可 具体 化 的 
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reified 具体 化 的 
remainder R 
restricted marker interface 有 限制 的 标记 


rounding mode 舍 和 人 模式 

runtime exception 运行 时 异常 

safety 安全 性 

scalar type 标量 类 型 

semantic compatibility “语义 兼容 性 
serial version UID 序列 版 本 UID 
serialization proxy ”序列 化 代理 
serialized form 序列 化 形式 

serializing ”序列 化 

service provider framework 服务 提供 者 


signature “签名 

singleton 单 例 

singleton pattern 单 例 模式 
skeletal implementation ”骨架 实现 
state transition ”状态 转变 
stateless 无 状态 的 

static factory method 静态 工厂 方法 
static member class 静态 成 员 类 
storage pool 存储 池 

strategy enum ”策略 枚 举 
strategy interface 策略 接口 


strategy pattern 策略 模式 
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stream unique identifier ” 流 的 唯一 标识 符 
subclassing 子 类 化 

subtyping 子 类 型 化 

synthetic field 合成 域 

thread group ”线程 组 

thread safety 线程 安全 性 

thread-safe 线程 安全 的 

顶级 类 ， 顶 县 类 

type inference 类 型 推导 

type parameter 类 型 参数 

typesafe 类 型 安全 

typesafe enum pattern 类 型 安全 的 枚 举 模 


top-level class 


式 

typesafe heterogeneous container 类 型 
安全 的 异 构 容 器 

unbounded wildcard type 无 限制 的 通 配 
符 类 型 : 

unchecked exception 未 受 检 异 常 

unintentional object retention 无 意识 的 
对 象 保持 


utility class 工具 类 
value class 值 类 

value type 值 类 型 

view ”视图 

virgin state ”空白 状态 
worker thread ”工作 线程 
wrapper class ”包装 类 
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